Start by comparing Chrome and Edge with clean profiles, not with your daily browser tabs. The ERR_TOO_MANY_REDIRECTS message usually means the browser was sent in a loop between two or more URLs, such as HTTP to HTTPS, non-www to www, or login to logout and back again. Because Chrome and Edge are both Chromium-based, they behave alike in many cases, but their privacy settings, profiles, extensions, and enterprise controls can expose different clues.
TLDR: Use Chrome and Edge side by side to separate a browser problem from a site configuration problem. For example, if Chrome shows the error after 20 redirects but Edge loads the page in 1.9 seconds using a fresh InPrivate window, suspect Chrome cookies, extensions, or cached site data. In one realistic support case, clearing only the affected site’s cookies fixed 7 out of 10 user reports, while the remaining cases traced back to HTTPS rules at the server or CDN. Do not start by reinstalling the browser; that wastes time and often changes nothing.
What the error really means
ERR_TOO_MANY_REDIRECTS appears when a browser follows repeated redirect instructions and stops for safety. A normal redirect might send http://example.com to https://example.com. A bad setup might send https://example.com back to http://example.com, then repeat until the browser gives up.
The most common causes are:
- Bad HTTP to HTTPS rules on the server, CDN, or reverse proxy.
- Conflicting www and non-www rules, such as
example.comtowww.example.comand back again. - Corrupt or stale cookies, especially for login pages.
- Cached redirects stored by the browser.
- Security plugins or web application firewalls that keep bouncing requests.
- Proxy headers missing from a load balancer, such as
X-Forwarded-Proto.
Chrome vs Edge: why the same site may act differently
Chrome and Edge share the Chromium engine, so their core redirect handling is very similar. That is useful. If both fail in a clean state, the site is probably misconfigured. If only one fails, the issue is more likely tied to browser data, privacy controls, an extension, or a managed policy.
Chrome is often the first browser used by developers and support teams. Its DevTools are familiar, and many testing guides are written around Chrome. It also tends to hold years of cookies, cached redirects, and extension residue because users rarely reset it.
Edge is strong for comparison testing on Windows. It may use different profiles, different tracking prevention settings, and company policies. Edge can also include features such as Internet Explorer mode in managed environments. That can confuse testing if the browser is controlled by IT policy.
Honestly, it feels like half the work is proving that the browser is not the real culprit. A clean Edge window can save 15 minutes when Chrome has old session cookies stuck to the site like glue.
Quick test order that actually works
Use this order before touching server settings. It is simple, repeatable, and safe.
- Open the site in Chrome Incognito. Press
Ctrl + Shift + Non Windows or Linux, orCommand + Shift + Non macOS. - Open the same URL in Edge InPrivate. Press
Ctrl + Shift + N. - Test the exact same URL. Do not add or remove
www, trailing slashes, or query strings. - Record what happens. Note the browser, URL, result, and time.
- Disable extensions only if one browser fails. Ad blockers, privacy extensions, password managers, and security tools can interfere with authentication redirects.
If both private modes fail, stop blaming local cookies. The server, CDN, redirect rules, or application code is the likely source. If only normal mode fails, clear site data for that domain.
Clear cookies and site data without wiping everything
Do not clear your entire browser history unless you have no other choice. It drives me crazy that many guides still suggest a full wipe first. That can log users out of dozens of services and still miss the real problem.
In Chrome:
- Open
chrome://settings/siteData. - Search for the affected domain.
- Delete only that site’s stored data.
- Restart the browser and test again.
In Edge:
- Open
edge://settings/siteData. - Search for the affected domain.
- Remove the entries for that site.
- Close all Edge windows and retest.
This is especially effective for login loops. A damaged session cookie can make an application think the user is both authenticated and not authenticated. The result is a loop between /login, /account, and /logout.
Use DevTools to see the loop
Both Chrome and Edge include excellent Developer Tools. Press F12, open the Network tab, and enable Preserve log. Then reload the page.
Look for repeated status codes:
- 301: permanent redirect.
- 302: temporary redirect.
- 307: temporary redirect that keeps the same method.
- 308: permanent redirect that keeps the same method.
The key column is Location. That shows where each redirect points. If you see http:// changing to https://, then back to http://, you have a protocol loop. If the domain flips between www and non-www, check DNS, hosting rules, CDN settings, and application base URL settings.
Chrome and Edge display this data in almost the same way. Chrome may feel more familiar to developers. Edge is often better for checking whether the problem affects a standard Windows user profile under company controls.
Check browser privacy and security settings
Edge has Tracking prevention settings: Basic, Balanced, and Strict. Strict mode can break some login flows, especially if a third-party identity provider is involved. Chrome has its own privacy controls around third-party cookies, safe browsing, and site permissions.
If a login loop appears only in Edge, test with Tracking prevention set to Balanced. If it appears only in Chrome, check whether third-party cookies are blocked for the identity provider domain. This matters for single sign-on systems such as Microsoft Entra ID, Okta, Auth0, and similar services.
Extensions deserve suspicion too. Test with all extensions disabled, not just the one you dislike. Password managers and coupon extensions sometimes inject scripts at the worst possible moment.
When the site is the problem
If Chrome and Edge both fail in private windows, focus on the server side. Common mistakes include forcing HTTPS in two places, setting the wrong WordPress or CMS site URL, or having a CDN talk to the origin over HTTP while the origin forces HTTPS.
For sites behind Cloudflare, Fastly, Akamai, nginx, Apache, or a load balancer, check the redirect chain from outside the browser. Use a command such as:
curl -IL https://example.com
This shows headers and redirect targets without browser cookies. If curl loops too, browser fixes will not solve it. Review canonical URL rules, SSL mode, proxy headers, and application configuration.
Which browser is better for troubleshooting?
Chrome is better for developer-led debugging because many teams already use it, and its DevTools workflow is widely understood. It is a good first choice when you need screenshots, HAR files, or quick inspection of redirect headers.
Edge is better as a second opinion on Windows, especially in business environments. It helps reveal whether policies, profile sync, security baselines, or Microsoft account settings are part of the issue.
The best answer is not Chrome or Edge alone. Use both. If they fail the same way in clean sessions, escalate to server configuration. If they differ, compare cookies, extensions, tracking settings, and managed policies. That split saves time and reduces guesswork.
Practical final checklist
- Test the exact URL in Chrome Incognito and Edge InPrivate.
- Clear only the affected site’s cookies and cached data.
- Disable extensions if only one browser fails.
- Use DevTools Network with Preserve log enabled.
- Check for repeated 301, 302, 307, or 308 responses.
- Compare third-party cookie and tracking prevention settings.
- Run
curl -ILto confirm whether the server is looping.
The safest rule is simple: treat Chrome and Edge as comparison tools, not rivals. Redirect loops are usually caused by bad state or bad rules. The browser that fails first is only the messenger.
