When I type in a URL and hit enter, for example abc.com, I don't expect to end up somewhere else. I expect an error page if there isn't a site with that URL. But instead I get redirected to another URL (another domain even: abc.go.com).

I'm no expert on web technology, but as far I can tell there are two main categories of redirect, DNS/registrar redirects (invisible) and server side redirects (visible, http code 301 or 302).

How do I prevent these server side redirects in Chrome? Best case scenario I get a prompt page telling me the page has a different URL or IP, asking if I want to continue.

Another example is hackoverflow.com I get redirected to two sites from here, after the first redirect I can glimpse a designed homepage before being moved on to a parking site. I'd like to stop halfway this double redirect and examine the second site.


6 Answers 6


I realize this is far from a perfect answer, as this will only work for responses that serve up content, but I decided to post it as there are currently zero useful, actionable answers.

As a quick-and-dirty solution you may be able to use the debugger (accessible by F12 or CTRL+SHIFT+I in most browsers) to give your self an opportunity to opt out of a redirect.

Run this line in the console before the page runs any scripts of its own:

window.onbeforeunload = function(){ return 'Leave page?'; };

For example, using Chrome:

  • Open the debugger (F12) and switch to the Sources tab.
  • Press F8 to put the debugger into step-through mode.
  • Navigate to the problematic page. It will begin to load but the debugger won't allow scripts to run.
  • Paste the above code into the console and hit enter.
  • Press F8 again to allow scripts to run and let the page finish loading.
  • Now you will see a prompt before any redirect occurs and you'll have an opportunity to cancel it.
  • If the page repeatedly tries to redirect you, you can tell chrome not to display the dialog again. Further attempts by the page to navigate you elsewhere will fail silently.

Prompt restores user control

  • 3
    Doesn't not work, pause is cancelled when loading the problematic page
    – hymced
    Sep 5, 2020 at 12:41
  • It certainly won't work in all circumstances and may not necessarily work on all browsers.
    – snarf
    Sep 6, 2020 at 14:27
  • Thank you dude! window.onbeforeunload = function(){ return 'Leave page?'; }; works like charm Mar 20, 2022 at 15:49
  • is there any plugin or approach to keep that code running permantly on the browser? Mar 20, 2022 at 15:50
  • @ChrisRusso: yes TamperMonkey/GreaseMonkey or similar extensions for userscripts
    – fferri
    Dec 27, 2023 at 22:02

Another temporary way to stop a redirect from happening, is to press esc button before the redirect happens.

esc stops the execution of js in the page but also html from rendering, so it it's pressed soon enough the redirect shouldn't take place but maybe the page won't be completely loaded. It can be useful to investigate page content and other info like cookies


In my experience with this problem there isn't a great way to handle this in every situation. Just the other day I ran into this problem while analyzing a banking phishing scam. I was looking for a reminder on this problem myself because it had been a while. I tried changing things in chrome to make the page stop redirecting automatically, but nothing worked. The reason it wasn't working is because this is what was at the top of the page:

        <meta content='0;URL=&#39;https://scam-website-two.scam&#39;' http-equiv='refresh' />
    <!-- other HTML here -->

That meta tag was redirecting to a second scam website after reaching the first scam website. More information about redirecting with the meta tag here.

Therefore, as far as I can tell I couldn't stop the redirect. I didn't care though because my fallback work around for annoying situations like this are to just download the web page as a text file and analyze the contents which is exactly what I did.

There are a variety of ways to do this. Since I was working inside of my dedicated Linux VM where I analyze scams I did the following inside of terminal (bash):

content=$(wget http://scam-website-one.scam -q -O -)

echo $content > scam.html

Credit where credit is due

In summation the basic algorithm is:

  1. Choose a language
  2. Perform an HTTP GET on your trouble URL
  3. Store output string to a variable
  4. Save output string to file

Like I mentioned before, this will help you at least see what is causing the redirect. After downloading the file, I removed that meta tag and then I was able to review the page.

  • I didn't want to make this part of the answer because I am not too familiar with it, but recently I started learning about Burp Suite. Might help here too. portswigger.net/burp Mar 27, 2022 at 23:00

Using the Dev Tools, there is a tab that will display all the assets initialized by a page and their source as a URL (Networking? Sources?); even easier, after closing a popup, go to your history and see the URL there.. Either way, if you know the server address ("popup.ads.com" etc) Then why not make an edit to your HOSTs file (Linux/Win/Mac compatible) and just not run the risk of having a sketchy site read/write cookies, and potentially try to hijack your browser?

All that you'd need to do is add a line for each domain to block such as: ads.com Or popup.ads.com (Sub domains can be blocked while leaving the parent domain unblocked)

  • 4
    I fail to see how this answers the question.
    – jiggunjer
    Apr 14, 2021 at 5:30
  • Seems I misunderstood the intent. @snarf takes a similar approach and addresses the intent to stop the redirect (without just routing the request to null). I had read the OP as though you were trying to blacklist the site(s) affected--as opposed to just preventing the redirect(s)
    – JoeBro
    May 7, 2021 at 16:50

As far as I know, there is no way to disable this function.

More importantly, doing so would break a very basic functionality that Web Servers rely on. You can expect a lot of websites to just stop working.

At bare minimum, - all 'www' redirects would stop working - all 'http-to-https' redirects would stop working

So you would manually have to type in 'https://www' before every domains.

Beyond that, many subpages within websites would stop functioning as well.

So I would not be surprised if Chrome and Firefox developers make it very difficult or impossible to disable Redirects altogether at the browser level.

  • So this security risk is actually a web feature?
    – jiggunjer
    May 7, 2020 at 5:57
  • 2
    Absolutely. It is built into HTTP protocol. A redirect is a server response 301 or 302.
    – madacoda
    May 7, 2020 at 7:04
  • 3
    This is somewhat like saying adblockers don't make sense and would break the web. Wanting to prevent redirects when they have harmful or counter-productive effects shouldn't be a non-starter. OP described a scenario where a page loads before the browser is redirected. This is a scenario I've run into many times. Regardless of the response code, if there is a page served, I would like to have the option of viewing that page.
    – snarf
    May 31, 2020 at 17:41
  • 9
    It would also be useful for developers trying to debug redirect problems. Nov 9, 2020 at 23:37
  • 3
    That's not an answer. Like @david-moles I'm here because I'm need to debug redirect pages and don't care about any of the potential drawbacks. I need to stop on the page which redirects to debug / test stuff.
    – Martin
    Sep 7, 2021 at 6:27
  • Open Google Chrome.
  • Update Google Chrome.
  • Click ⋮.
  • Click Settings.
  • Scroll down and click Advanced ▼.
  • Scroll right down to the "Privacy and security" segment.
  • Click the grey "Protect you and your device from risky sites" switch.
  • Use an extension.
  • I'm not sure why so many downvotes. It's a reasonable option, and is a better response than some. I'm not going to upvote it though, because it's short on reasons.
    – Auspex
    Jun 1, 2021 at 10:22
  • Sadly that doesn't work. I guess sites started to use workarounds.
    – Martin
    Sep 7, 2021 at 6:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .