Fix ERR_TOO_MANY_REDIRECTS in Chrome

ERR_TOO_MANY_REDIRECTS is Chrome’s redirect safety valve. When a site sends Chrome bouncing between URLs more than a set number of times — Chrome’s limit is around 20 — it stops rather than loop forever. The error page says “This page isn’t working” and explains the site redirected you too many times. That’s technically accurate, but it doesn’t tell you the part that actually matters: whose fault is it? If you want the full context, see our Google Chrome Errors.

In most cases, it’s a stale cookie sitting in Chrome from a previous visit. The cookie instructs the server to redirect, the redirect produces another redirect instruction, and the loop runs until Chrome gives up. In a minority of cases the redirect loop is on the server itself — a configuration problem that affects every visitor regardless of what’s in their browser. Figuring out which situation you’re in takes about thirty seconds.

Start Here: Is This a Chrome Problem or a Server Problem?

Open the same site in Firefox or Edge. This is the most valuable diagnostic step and it costs almost nothing. If another browser loads the site without issue, the redirect loop is definitely caused by something in Chrome — and since it’s browser-specific, a cookie is almost always to blame. If Firefox also loops and shows a redirect error, every visitor is affected, which means the site’s configuration is broken and only the site owner can fix it.

Also try: open the site in Chrome Incognito mode (Ctrl + Shift + N). Incognito starts with no cookies from previous sessions. If the site loads fine in Incognito but loops in a normal window, you’ve just confirmed the cookie diagnosis — and the fix is deleting those cookies from Chrome’s normal session.

Fix 1: Clear Cookies for the Specific Site

This resolves the majority of ERR_TOO_MANY_REDIRECTS cases where Incognito loads fine and other browsers work. A cookie from a previous visit is the culprit — it might be a session cookie from when the site had a different URL structure, an auth cookie forcing a login redirect loop, or a tracking cookie from an A/B test that no longer exists on the server but Chrome is still presenting on every visit.

The quickest approach is to delete cookies directly from the address bar:

1. While on the tab showing ERR_TOO_MANY_REDIRECTS, click the lock icon (or info icon) to the left of the URL
2. Click Cookies and site data
3. Click Manage cookies and site data
4. Delete all entries for the affected domain
5. Reload the page

Alternative: go to chrome://settings/siteData, search for the domain name, and click the bin icon next to every matching entry. Faster if there are many entries. The result is the same — Chrome approaches the site with no prior cookie state, the redirect loop can’t start, and the site loads normally.

If clearing site-specific cookies doesn’t fix it, move to the broader cache clear below. Sometimes the redirect instruction is cached rather than cookied.

Fix 2: Clear All Chrome Browsing Data

When site-specific cookie clearing doesn’t resolve the loop, clearing Chrome’s full cache forces a completely fresh state. Redirect instructions can sometimes be cached in Chrome’s network cache rather than stored as cookies — particularly for HTTP-to-HTTPS redirects and canonical URL redirects that the browser has learned to apply locally.

1. Press Ctrl + Shift + Delete
2. Set the time range to All time
3. Check: Browsing history, Cookies and other site data, Cached images and files
4. Click Clear data
5. Restart Chrome completely and try the site

Fix 3: Check for Redirect-Modifying Extensions

URL redirector extensions, certain ad blockers, and privacy tools that rewrite URLs can interfere with a site’s intended redirect chain — intercepting the redirect, modifying it, and sending Chrome to a URL that triggers another redirect. The loop becomes self-reinforcing with the extension contributing to each cycle.

Since Incognito disables extensions by default, if the site loads in Incognito you’ve already narrowed this down to either cookies or extensions. To isolate which:

1. After clearing cookies per Fix 1 — if the site still loops in a normal window but works in Incognito, extensions are the remaining variable
2. Go to chrome://extensions and toggle all extensions off
3. Test the site in a normal Chrome window
4. Re-enable extensions one at a time until the redirect loop returns — the last one enabled is the cause

Common culprits: redirect tracking protection in ad blockers (like uBlock Origin’s “prevent WebRTC leaks” settings), HTTPS Everywhere or similar forced-HTTPS extensions creating conflicts with sites already handling their own HTTPS redirect, and some password managers that try to intercept login redirects.

Fix 4: When the Server Is the Problem

If ERR_TOO_MANY_REDIRECTS appears in every browser, on multiple devices, and in Incognito mode — the redirect loop is happening before Chrome has any cookies to contribute. The site’s server is configured to redirect in a way that loops back to itself. This is a server-side problem and only the site owner can fix it, but understanding what typically causes it is useful if you own the site.

HTTP to HTTPS misconfiguration is the most common cause. The server is configured to redirect HTTP to HTTPS, but a load balancer or proxy upstream strips the HTTPS flag and forwards requests to the web server over HTTP. The server always receives what looks like an HTTP request, always redirects to HTTPS, and the loop runs indefinitely. The fix is configuring the server to trust the X-Forwarded-Proto header that the load balancer sets rather than relying on the connection type the server itself receives.

WordPress URL settings conflict is the second most common cause I’ve seen. WordPress stores the Site URL and Home URL in the database. If one is configured as http:// and the other as https://, or if one uses www and the other doesn’t, WordPress creates an infinite redirect between the two versions. Check Settings → General and ensure WordPress Address and Site Address both use exactly the same protocol and subdomain format.

CDN or reverse proxy redirect conflicts happen when the CDN in front of the server has redirect rules that contradict the server’s own rules. Cloudflare, for instance, has redirect rules configurable in the dashboard that can conflict with .htaccess redirect rules on the origin server — both redirect layers end up chasing each other. Check both the CDN dashboard rules and the server-side redirect configuration to ensure they’re not working against each other.

Fix 5: Check HSTS Preload State

This is an edge case, but worth mentioning because it causes ERR_TOO_MANY_REDIRECTS in a way that’s genuinely confusing. HSTS (HTTP Strict Transport Security) allows sites to tell browsers “always load me over HTTPS, never HTTP.” Chrome maintains a preload list and a per-site HSTS state. If a site was previously loaded over HTTPS and set an HSTS policy, Chrome will force-redirect HTTP access to HTTPS before the request even leaves the browser. This normally works fine — but if the site is now serving content that triggers its own HTTP redirect, Chrome’s pre-flight HTTPS redirect and the server’s redirect rules can conflict in a way that produces ERR_TOO_MANY_REDIRECTS specifically in Chrome.

To clear Chrome’s HSTS state for a specific domain:

1. Go to chrome://net-internals/#hsts
2. In the “Delete domain security policies” section, enter the domain (without https:// or www)
3. Click Delete
4. Reload the page

This only applies when the site previously worked in Chrome and started redirecting looping after a server configuration change. If HSTS is the issue, deleting the policy entry often resolves the Chrome-specific loop immediately.

Quick Reference

Our guide on This site can’t be reached covers the broader connection errors that sometimes accompany redirect issues when a site has multiple configuration problems simultaneously. For SSL-related redirect loops specifically, our ERR_SSL_PROTOCOL_ERROR guide covers cases where HTTP-to-HTTPS redirect loops are caused by TLS handshake failures rather than redirect configuration problems. Google’s developer documentation covers redirect best practices and how to correctly implement HTTP-to-HTTPS redirects in ways that don’t create loops.

A practical note for web developers who own sites showing ERR_TOO_MANY_REDIRECTS in production: Chrome’s DevTools (F12 → Network tab) shows the full redirect chain when you load a URL. Even with ERR_TOO_MANY_REDIRECTS stopping Chrome from loading the page, the Network tab captures every redirect step Chrome followed before giving up — which makes it straightforward to identify exactly which URL is creating the loop and which response header is causing the redirect at each step. This makes debugging server-side redirect loops significantly faster than reading through server access logs.

One thing that’s easy to overlook with ERR_TOO_MANY_REDIRECTS: the error appears before Chrome loads any page content, which means the site’s own analytics, error pages, and diagnostic tools aren’t available to the visitor. Site owners investigating redirect loops reported by users can use curl to trace the redirect chain without a browser — curl -v -L "https://example.com" 2>&1 | grep -E "Location|HTTP/" shows every redirect hop and the HTTP status code at each step. This is much faster than trying to reproduce the loop in different browser environments and immediately shows where the loop starts and where it returns to.

Third-party login integrations add another dimension to ERR_TOO_MANY_REDIRECTS that affects a specific type of user: if a site uses OAuth (Google login, Facebook login, or similar), the OAuth flow involves multiple redirects between the site and the identity provider. A misconfigured redirect URI in the OAuth settings — one that doesn’t match what the site actually uses after the login flow — can create a loop that affects only users trying to log in, while the rest of the site works normally. If ERR_TOO_MANY_REDIRECTS only appears when you click a “Sign in with Google” or similar button, the OAuth redirect configuration is the likely cause, and clearing cookies won’t help — the site owner needs to correct the authorized redirect URI in their OAuth application settings.

Browser extensions that enforce HTTPS — like the legacy HTTPS Everywhere extension or certain ad-blocker configurations with HTTPS upgrade rules — occasionally create ERR_TOO_MANY_REDIRECTS on sites where the developer intended to serve certain pages over HTTP while others go over HTTPS. The extension upgrades every HTTP request to HTTPS, the server redirects back to HTTP for that specific page, the extension upgrades it again, and the loop continues. Modern Chrome has built-in HTTPS-First Mode (Settings → Privacy and security → Security → Always use secure connections) which does the same thing as HTTPS Everywhere — if enabling this setting coincides with when ERR_TOO_MANY_REDIRECTS started appearing on a specific site, temporarily disabling HTTPS-First Mode and testing confirms whether that’s the cause. This particularly affects legacy sites and internal tools that haven’t yet migrated to HTTPS on all pages.

Caching at the CDN layer can make ERR_TOO_MANY_REDIRECTS very difficult to diagnose because cached redirect responses continue being served even after the underlying configuration that caused the loop has been fixed. If you or a site owner have corrected what appears to be the redirect configuration but visitors (and some browsers) are still seeing the loop, CDN cache purging is the likely missing step. Cloudflare, Fastly, and other CDN providers offer cache purging through their dashboards — purging the cache for the affected URLs forces the CDN to fetch fresh responses from the origin server with the corrected configuration. Until the CDN cache is purged, some visitors will continue receiving the cached redirect loop responses regardless of what was fixed on the origin.

Mobile browsers and ERR_TOO_MANY_REDIRECTS behave slightly differently from desktop Chrome. On Android, Chrome for mobile uses the same cookie store and redirect-handling behaviour as desktop Chrome, so the cookie-clearing fix (Fix 1) applies the same way — go to Settings → Privacy and security → Clear browsing data → and select Cookies and site data. On iOS, Chrome uses Apple’s WebKit rendering engine rather than Blink, which can mean the redirect loop behaves differently — a site that loops in Chrome on iOS but not in Safari on the same device suggests a cookie or session-related cause rather than a network or SSL issue. The diagnostic logic remains the same: if Incognito in Chrome for iOS loads the site but the normal browser doesn’t, clear the cookies for that site and the loop should stop. See also Chrome Too Many Redirects Error for a related case.