Too Many Redirects in Chrome: Break the Loop

The “too many redirects” error in Chrome (ERR_TOO_MANY_REDIRECTS) means a page is stuck in a loop — Chrome visits the URL, gets redirected to another URL, which redirects back to the first, which redirects again, indefinitely. Chrome stops after a set number of iterations and shows the error rather than looping forever. For a broader walkthrough, our Google Chrome Errors is a good next read.

The most important thing to know first: this error is usually caused by either cookies or a misconfigured server. The fix for the cookie case is immediate and takes 30 seconds. The server misconfiguration case means the website itself needs to be fixed.

Fix 1: Clear cookies for the specific site (start here)

Outdated or corrupted cookies are the most common client-side cause of redirect loops. Cookies store session state, authentication tokens, and preferences — when one of these stored values triggers a redirect that conflicts with the server’s current redirect rules, you get a loop.

Clear cookies only for the affected site, not all sites (no need to lose all your logins):

1. Click the lock icon in Chrome’s address bar → Cookies and site data
2. Select the relevant site(s) → Remove all → Done
3. Reload the page

Alternatively: Ctrl+Shift+Delete → select “Cookies and other site data” → change the time range to “Last hour” → clear. This removes recent cookies without touching older ones from other sites.

If the page loads after clearing cookies: the old cookie was the cause. The site sets a fresh one on your next visit and you’re back to normal.

Fix 2: Test in Incognito

Ctrl+Shift+N → open the failing URL. Incognito mode uses no stored cookies or session data. If the page loads in Incognito but not in regular Chrome: cookies or an extension in regular mode is causing the loop. If it also fails in Incognito: the issue is server-side (the website itself has the redirect misconfiguration).

This test takes 10 seconds and tells you whether to focus on Chrome configuration or wait for the website to fix their server. Don’t spend time on Chrome settings if Incognito also fails — the problem isn’t on your end.

Fix 3: Disable HTTPS redirect handling

Many redirect loops involve HTTP→HTTPS redirect conflicts. The server sends “Redirect to HTTPS” but the HTTPS version itself redirects somewhere else, creating a loop. Check whether the site works with https:// explicitly typed at the start of the URL (instead of letting Chrome auto-complete). Also try http:// if HTTPS is the one looping.

Chrome has HSTS (HTTP Strict Transport Security) preloading that forces HTTPS for known domains. If a site’s HSTS record is cached but the site’s HTTPS is broken: a redirect loop can result. Clear HSTS for the specific site: chrome://net-internals/#hsts → in the “Delete domain security policies” field → type the domain name → Delete. Then try the site again.

Fix 4: Check extensions

Privacy extensions, VPN extensions, and HTTPS enforcement extensions (HTTPS Everywhere, Smart HTTPS) can create redirect loops by forcing an HTTPS redirect that conflicts with the server’s own redirect rules.

Disable all extensions: chrome://extensions → toggle off everything → reload the failing page. If it loads: re-enable extensions one at a time to find the culprit. HTTPS-enforcement extensions on sites that don’t fully support HTTPS are a classic cause of ERR_TOO_MANY_REDIRECTS.

Fix 5: DNS and proxy

A DNS configuration issue that points a domain to the wrong IP can produce redirect-like behaviour if the wrong server also has redirect rules. If the redirect loop error appeared around the same time as DNS changes:

• Open Command Prompt → ipconfig /flushdns → retry
• Try accessing the site on a different network (phone mobile data) to confirm the domain resolves correctly elsewhere
• Check proxy settings (Settings → System → Open your computer’s proxy settings) — a misconfigured proxy can cause redirect-like errors

When the website itself is the problem

If Incognito mode also fails, the issue is server-side. Common server-side redirect loop causes:

• WordPress sites: a mixed HTTP/HTTPS configuration in wp-config.php or the database, where the site URL is set to HTTP but the server forces HTTPS
• Web hosting that forces www prefix conflicting with site redirect to non-www (or vice versa)
• CDN (Cloudflare, etc.) HTTPS settings conflicting with the origin server’s HTTP settings — the “Flexible SSL” mode on Cloudflare is a classic cause of this
• A newly changed SSL certificate or domain change that has conflicting redirect rules still cached

If you own the affected website: these are the configurations to investigate. If you’re a visitor: there’s nothing you can do except wait for the site owner to fix it, or try the site on a different browser to confirm it’s not just a Chrome-side issue.

Our guide on Chrome connection errors covers the ERR_CONNECTION_REFUSED and related network-level failures that look similar to redirect errors. For DNS configuration issues affecting multiple sites, our DNS troubleshooting guide covers the Windows DNS stack and cache. Chrome’s developer tools documentation covers the Network tab’s redirect chain view — pressing F12 → Network tab → reload shows every redirect step including which server sent each redirect and what it contained, making server-side redirect debugging precise.

Using Chrome’s Network tab to diagnose the redirect chain

F12 → Network tab → check “Preserve log” → reload the failing page. The Network tab shows every HTTP request and response in sequence. Filter by “Type: Doc” or look at the first few entries — you’ll see the actual redirect chain:

1. Click each 301 or 302 response in the waterfall
2. Click “Headers” → look at the “Location” response header — this is where the server is redirecting you
3. Follow the chain of Location headers to see where the loop starts

A typical loop looks like: example.com → www.example.com → example.com → www.example.com → (loop). Once you can see the exact loop pattern, the cause is usually obvious — a www/non-www redirect conflict, an HTTP/HTTPS conflict, or a regional redirect that creates a circular path.

Cloudflare SSL mode and redirect loops

If you manage a website on Cloudflare and visitors report redirect loops: the SSL/TLS mode setting is the most common cause. The Flexible SSL mode (Cloudflare encrypts traffic between visitor and Cloudflare, but uses HTTP to the origin server) causes loops when the origin server itself also forces a redirect to HTTPS — because Cloudflare sends HTTP to the origin, which redirects to HTTPS, which goes back through Cloudflare, which sends HTTP again, and so on.

Fix: Cloudflare dashboard → SSL/TLS → change from “Flexible” to “Full” or “Full (strict).” This tells Cloudflare to use HTTPS when connecting to the origin server, breaking the redirect loop. Full (strict) requires a valid certificate on the origin; Full works with self-signed certificates.

WordPress redirect loop fixes

WordPress sites frequently suffer redirect loops after domain changes, SSL certificate additions, or plugin conflicts. Common causes and fixes:

• Site URL mismatch: wp-config.php has define('WP_HOME','http://...') or WP_SITEURL set to HTTP while the server forces HTTPS. Update these values to HTTPS
• Database URLs: the siteurl and home options in the wp_options table still point to HTTP. Update via phpMyAdmin or WP-CLI: wp option update siteurl 'https://example.com' and wp option update home 'https://example.com'
• Plugin conflict: deactivate all plugins by renaming the /plugins/ folder → test if the loop stops → re-enable plugins one at a time
• .htaccess rules: conflicting redirect rules in .htaccess create loops. Regenerate .htaccess from WordPress admin (Settings → Permalinks → Save Changes) to reset it to defaults

Third-party cookies and redirect loops

Some authentication systems use third-party cookies (cookies set by a login service domain rather than the site domain) for session management. When third-party cookies are blocked — Chrome’s default behaviour in certain modes, and the direction the web is moving — the auth system can’t read the session cookie and repeatedly redirects to the login page, creating a loop.

Temporary test: Chrome Settings → Privacy and security → Third-party cookies → change to “Allow third-party cookies” → reload the failing page. If it works: the site depends on third-party cookies for authentication. For sites you trust and regularly need: add them to the “Always allow” list in the same section. For sites you don’t trust: the redirect loop is a symptom of the site using a privacy-hostile authentication pattern.

Redirect loops after login

A redirect loop that specifically occurs on the login page (you submit credentials → redirect loop begins) is almost always a session cookie or CSRF token issue. The server sends you to a post-login redirect URL, but the session isn’t established correctly so it sends you back to login, creating a loop.

Fix: clear site cookies and cache → log in again with a fresh session. If it happens consistently: the site has a misconfigured login redirect, often a hardcoded redirect URL that doesn’t match the current domain (common after site migrations). The site owner needs to fix this.

ERR_TOO_MANY_REDIRECTS in specific apps using Chrome

Apps that embed Chrome’s browser engine (Electron apps, some enterprise portals using CEF/WebView) can show redirect errors in their embedded browser that don’t appear in standalone Chrome. The cause is usually the app’s custom proxy, authentication, or URL handling conflicting with a site’s redirects.

Test the same URL in regular Chrome — if it works in Chrome but not in the embedded browser: the app’s configuration is adding something to the request (custom headers, proxy routing) that the site interprets differently. Reporting to the app’s IT support team or vendor is the appropriate path, as users can’t modify the embedded browser’s behaviour.

Quick summary table

Test result	Cause	Fix
Works in Incognito, fails in regular Chrome	Cookies or extension	Clear site cookies; disable extensions
Fails in Incognito too	Server-side redirect misconfiguration	Nothing you can do as a visitor; wait for site fix
Only fails on one specific site	Site-specific cookie or HSTS conflict	Clear cookies + HSTS for that domain
You manage the site (WordPress)	HTTP/HTTPS URL mismatch	Update wp-config.php and database URLs
Site on Cloudflare	Flexible SSL mode	Change SSL mode to Full or Full (strict)
Occurs after login specifically	Session cookie issue	Clear cookies; site may need server fix

The Incognito test remains the most important first step — it categorically separates “this is a Chrome configuration problem” from “this is the website’s problem,” which saves significant time by eliminating the wrong investigation path entirely.

Mobile Chrome redirect loops

If the redirect loop occurs in Chrome on Android or iOS but not on desktop Chrome: the mobile browser is likely hitting a different server configuration. Many sites have separate mobile redirect rules that send users to m.example.com or to the app store. When these rules are misconfigured, mobile users get redirect loops while desktop users see the site normally.

Test: in mobile Chrome, request the desktop site (three-dot menu → Request desktop site) — if this resolves the loop, the mobile redirect rules are the problem. Report to the site owner with this specific information.

Redirect loops and geographic restrictions

Some sites use geographic redirects that create loops when geolocation detection fails or when users are in unexpected regions. A VPN that puts you in a region the site doesn’t serve correctly can trigger a redirect loop as the site tries to send you to a regional version that doesn’t exist or loops back.

Test without the VPN if one is active. If the site loads without VPN but loops with it: the VPN’s exit location is causing a geographic redirect conflict. Switching to a different VPN server location (try the one closest to the site’s primary market) often resolves geographic redirect loops.

Redirect errors in Chrome are one of those issues where the fix is either instant (clear cookies, 30 seconds) or completely out of your hands (server-side misconfiguration). The Incognito test tells you which situation you’re in within 30 seconds — use it before anything else.

For developers dealing with redirect loops on their own sites: Chrome’s Network tab (F12) showing the exact redirect chain is more useful than any error message. The Location headers in each 301/302 response tell you precisely where the loop starts and which server component is responsible. The most efficient debugging approach is to trace the chain from the first request, identify where it starts looping, and then look at what changed in that component (hosting configuration, SSL setup, Cloudflare settings, WordPress options) around when the loop started.

And one last practical thing: if a site that previously worked starts showing redirect loops without any changes on your end, check whether the site recently moved to HTTPS (many sites do this silently), changed their domain, or had a CDN configuration update. These backend changes often introduce temporary redirect issues that get fixed within hours. Checking whether the site works on a different device or network quickly tells you if it’s a temporary server issue rather than something requiring your investigation. If this sounds familiar, How to Fix ERR_TOO_MANY_REDIRECTS in Chrome is worth a look.