ERR_TOO_MANY_REDIRECTS means Chrome asked for a page, got sent somewhere else, and that somewhere else sent it right back. Chrome followed the loop about 20 times, gave up, and showed you the error. If only one site does it, delete that site’s cookies and reload. If every site does it, the problem is your network or a proxy, not the site.
Before you start
- Applies to: Google Chrome on Windows, Mac, Linux, ChromeOS, Android, and iOS. Chrome for iOS shows the same error text.
- Chrome version: Not version-specific. This error has behaved the same way for years.
- You need: Nothing special. Every fix below is in Chrome’s own settings.
- Time: About two minutes for the common case.
What does ERR_TOO_MANY_REDIRECTS actually mean?
A redirect is a short reply from a web server that says “not here, go there instead.” Redirects are normal. They are how http:// becomes https://, how old page addresses still work, and how a login page hands you back to the page you wanted.
A redirect loop is what happens when two of those instructions disagree. Page A says go to Page B. Page B says go to Page A. Nobody ever serves a real page. Chrome does not follow that forever. It follows a redirect chain up to a fixed limit, roughly 20 hops, and then stops and shows ERR_TOO_MANY_REDIRECTS. Firefox uses a similar limit. Safari stops a little sooner.
The full message usually reads “This page isn’t working. example.com redirected you too many times.” Chrome often adds a hint underneath: “Try deleting your cookies.” That hint is genuinely useful, and it is a clue about the most common cause, which we will get to next.
People do run into this regularly. One reader in the Google Chrome Help Community reported every Google search result throwing the error while clearing cookies, cache, and history changed nothing. Another thread describes the same “redirected you too many times” wall on specific sites only. Those two reports sit on opposite branches of the diagnosis, which is exactly why a single fix list does not work here.
Which cause is yours?
Do this first. It takes 30 seconds and it decides everything that follows.
- Open a new tab and load two or three unrelated sites you know work, for example
wikipedia.organdbbc.com. - Open the broken site in an Incognito window (Ctrl+Shift+N on Windows or ChromeOS, Cmd+Shift+N on Mac).
- Open the broken site in a different browser, or on your phone using mobile data instead of Wi-Fi.
Now match your result to a branch:
- Branch 1: only one site fails, and it works in Incognito. A cookie stored for that site is stale or contradictory. This is your branch, and it is the easiest one.
- Branch 2: only one site fails, and it also fails in Incognito and on your phone. The site itself is misconfigured. Nothing you do in Chrome will fix it.
- Branch 3: many or all sites fail, and they work fine on mobile data or another network. Something between you and the internet is intercepting traffic: a VPN, a proxy, a captive portal, or school or office filtering.
- Branch 4: it started right after you changed a date, time zone, or system setting. A wrong clock can break the login handshakes that many redirects depend on.
Branch 1: fix a stale cookie for one site
When you sign in somewhere, the site stores a cookie that says “this person is logged in.” If that cookie expires oddly, gets corrupted, or was written by a different version of the site, the server can read it, decide you are not logged in, and bounce you to the login page. The login page reads the same bad cookie, decides you are logged in, and bounces you back. That is the loop.
Clear cookies for that one site only. You do not need to wipe everything.
- Open the broken site so its address is in the address bar.
- Click the View site information icon to the left of the address, then click Cookies and site data.
- Click Manage on-device site data.
- Click the trash icon next to the site, then click Done.
- Reload the page.
If the site has more than one domain involved, for example a separate login server, clear cookies for those too. In Chrome go to Settings → Privacy and security → Third-party cookies → See all site data and permissions, then search the site name and delete each match.
If clearing the cookie fixes it and the loop comes back a week later, the site is writing a bad cookie on purpose or by accident. Report it to them. There is no permanent fix on your end.
Branch 2: the site is misconfigured, and you cannot fix it
This is the honest part. If the loop happens in Incognito, in another browser, and on another network, the redirect is coming from the server. You are seeing someone else’s configuration mistake.
The most common version of this involves a CDN sitting in front of the site. Cloudflare documents the pattern plainly: if a site’s encryption mode is set to Flexible while the origin server forces HTTPS, Cloudflare talks to the origin over plain HTTP, the origin redirects to HTTPS, Cloudflare downgrades it again, and the loop never ends. Conflicting redirect rules and a misconfigured HSTS setting cause the same symptom.
What you can do as a visitor:
- Try the address with and without
www. Sometimes only one host is broken. - Try the
http://version. If it loads, the site’s HTTPS redirect is the broken piece. - Wait an hour and try again. These are usually caught and fixed quickly.
- If it is your own site, check your CDN encryption mode first, then your redirect rules, then your CMS’s site address setting.
Branch 3: a VPN, proxy, or network filter is in the way
If several unrelated sites fail at once, stop blaming cookies. Something is rewriting your requests.
Turn off your VPN and reload. If that fixes it, the VPN is redirecting traffic through a gateway that disagrees with the site. Try a different VPN server before giving up on the VPN entirely.
On a school, office, or hotel network, a captive portal may be trying to send you to its sign-in page while the site tries to send you back. Open http://neverssl.com in a new tab. That address does not force HTTPS, so the portal page can actually appear. Sign in, then retry the site.
Changing proxy settings affects every app on your computer, not just Chrome. Note what the current settings are before you change anything, so you can put them back.
To check Chrome’s proxy: go to Settings → System → Open your computer’s proxy settings. If a proxy is on and you did not set it up, that is worth investigating.
Extensions can do this too. Anything that redirects traffic, such as HTTPS-forcing extensions, ad blockers with custom rules, or privacy redirect tools, can create a loop with a site that already redirects. Because Incognito disables most extensions by default, an Incognito test that works while normal browsing fails points straight at an extension. Turn them off in Settings → Extensions, then re-enable them one at a time.
Branch 4: your clock is wrong
Many redirect chains are login handshakes, and login handshakes are time-sensitive. If your device clock is off by more than a few minutes, a token can be judged expired the moment it is issued. The site sends you back to sign in, issues another token, and the loop starts.
Set your clock to update automatically. On Windows go to Settings → Time & language → Date & time and turn on Set time automatically. On a Chromebook go to Settings → Advanced → Date and time and confirm the time zone. On Mac go to System Settings → General → Date & Time.
If none of this worked
Open chrome://net-export in a new tab and click Start Logging to Disk. Pick a file name and location, then reproduce the error in a different tab. The net-export tab has to stay open or logging stops on its own. Come back to it and click Stop Logging. The saved file shows the actual redirect chain, hop by hop. If you are contacting the site’s support team, that file tells them exactly where the loop starts, which is far more useful than “your site does not work.”
Resetting Chrome to defaults is a reasonable last step, but only if the error follows you across networks and sites and survives an Incognito test. That combination is rare, and it usually means an extension or a policy is involved rather than Chrome itself.
FAQ
Why does Chrome say to delete my cookies?
Because a stale login cookie is the single most common cause Chrome can guess at from the browser side. It is a good first suggestion, but it only helps Branch 1. If the loop also happens in Incognito, deleting cookies will not do anything.
How many redirects will Chrome follow before it stops?
Around 20. The exact number is a fixed limit built into Chrome’s networking code, not something you can raise in settings. A legitimate site almost never needs more than three or four hops, so hitting 20 always means a genuine loop rather than a long chain.
Does incognito mode fix ERR_TOO_MANY_REDIRECTS?
It does not fix it, but it is the best diagnostic you have. Incognito starts with no cookies and most extensions disabled. If the site loads there and fails in a normal window, the cause is on your device. If it fails in both, the cause is the site or the network.
Is ERR_TOO_MANY_REDIRECTS a virus?
On its own, no. It is an ordinary configuration error. That said, if you are also seeing unfamiliar pages open by themselves, or your search engine has changed, a browser hijacker could be adding redirects of its own. That is a separate problem with a separate fix.
The short version
Test in Incognito first. One site failing in a normal window but working in Incognito means clear that site’s cookies. Failing everywhere means the site is broken and you wait. Many sites failing at once means your VPN, proxy, or network is the culprit. Do the 30-second test before changing any settings, and you will skip most of the work.
