Safari Can’t Open the Page Because Too Many Redirects: Safari vs Chrome for Fixing Redirect Loops

AJ

Start by clearing data for the affected site, not your whole browser. Safari shows “Safari Can’t Open the Page Because Too Many Redirects” when a site keeps sending the browser from one URL to another until Safari gives up; Apple describes this as a page being redirected to open another page repeatedly [source: Apple]. Chrome usually calls the same problem ERR_TOO_MANY_REDIRECTS. The fix is often simple, but the fastest route depends on whether the loop lives in Safari’s privacy settings, Chrome’s cached cookies, or the website’s own server rules.

TLDR: Safari is more likely to expose redirect loops caused by cookies, tracking prevention, or login sessions, while Chrome is usually better for diagnosing the exact redirect chain. If one user can open a site in Chrome but Safari fails, clear only that site’s Safari data first; in many support cases, this takes under a minute and avoids wiping saved logins everywhere. For example, a shopper stuck between /cart and /login may fix it by deleting cookies for that store rather than resetting the whole browser. If both Safari and Chrome fail, expect a server-side issue such as HTTP to HTTPS rules, WordPress plugins, CDN redirects, or a bad authentication setting.

Why redirect loops happen

A redirect is normal. A site may send example.com to www.example.com, or http:// to https://. That is fine when it happens once or twice.

A loop starts when two or more rules fight each other. One rule sends you to Page A. Another sends you back to Page B. The browser tries again, then again, then throws an error. Honestly, it feels like watching a door that opens into the same hallway forever.

Common causes include:

  • Bad cookies: A stale login cookie says you are signed in, while the server says you are not.
  • HTTPS conflicts: A server forces HTTPS, but a proxy or plugin sends traffic back to HTTP.
  • WWW conflicts: One rule prefers www, another removes it.
  • CMS plugins: Security, cache, SEO, and redirect plugins can clash.
  • CDN settings: Cloudflare or another CDN may apply SSL settings that do not match the origin server.
  • Browser privacy tools: Cookie blocking, content blockers, and anti-tracking features may break a login flow.

Safari vs Chrome: which one is better for fixing it?

Chrome is better for diagnosis. It shows ERR_TOO_MANY_REDIRECTS, has strong developer tools, and makes it easier to inspect each hop in the redirect chain. If you are a site owner, Chrome is usually the better first tool.

Safari is better for catching privacy-related problems. Safari’s Intelligent Tracking Prevention and stricter cookie behavior can reveal issues that Chrome lets slide. This matters for logins, carts, payment pages, portals, and apps that bounce users through several domains.

The annoying part is Safari gives fewer clues. Chrome lets you open DevTools, record the Network tab, and see a chain like:

  1. http://site.com
  2. https://site.com
  3. https://www.site.com
  4. https://site.com

Safari can do this too with Web Inspector, but it takes extra setup. It drives me crazy that a simple browser error can turn into five minutes of menu digging before you even see the useful data.

Fast Safari fixes for “too many redirects”

Try these in order. Do not start by nuking all history unless you enjoy signing back into everything.

1. Remove data for the problem site

  1. Open Safari.
  2. Go to Safari > Settings.
  3. Click Privacy.
  4. Choose Manage Website Data.
  5. Search for the domain.
  6. Select it and click Remove.

This clears cookies and stored data only for that site. It is the cleanest first move.

2. Test a Private Window

Open File > New Private Window and try the page again. If it works there, your normal Safari profile likely has a bad cookie, cached redirect, or extension conflict.

3. Disable content blockers for the site

Content blockers can break login redirects or checkout pages. In Safari, open the site, click the settings icon in the address bar if available, and turn off blockers for that domain. You can also check Safari > Settings > Websites > Content Blockers.

4. Temporarily change privacy settings

Go to Safari > Settings > Privacy. If the site uses a third-party login provider, such as a company portal or payment service, test with stricter blocking disabled for a moment. Turn protections back on after testing.

Do this only for troubleshooting. If a site needs weak privacy settings forever, that site has a design problem.

Fast Chrome fixes for redirect loops

Chrome’s first fix is similar, but the path is often quicker.

1. Clear site data from the address bar

  1. Open the broken page.
  2. Click the icon next to the URL.
  3. Open Site settings.
  4. Click Delete data or clear stored data for that site.
  5. Reload the page.

This often fixes login loops in seconds.

2. Test Incognito mode

Press Command + Shift + N on Mac or Ctrl + Shift + N on Windows. If Incognito works, the issue is probably cookies, cache, or an extension.

3. Use DevTools to see the loop

Open View > Developer > Developer Tools, click Network, then reload the page. Look for repeated 301, 302, 307, or 308 status codes. Chrome documents these redirect-related HTTP status codes in its developer materials [source: Chrome Developers].

If you see the same two URLs repeating, you have proof. Send that chain to the site admin or hosting provider. It beats saying “the website is broken,” which usually gets a vague reply.

If Safari fails but Chrome works

This pattern points to Safari-specific storage or privacy behavior. Focus on:

  • Safari site data for that domain.
  • Cross-site login cookies, especially for SSO tools.
  • Content blockers that block scripts or tracking pixels used in sign-in flows.
  • iCloud Private Relay, VPN apps, or DNS filters.

Try the same page on an iPhone or iPad using Safari. If it fails there too, the website may not handle Safari well. That is common with older portals and clunky checkout systems.

If Chrome fails but Safari works

Chrome may be holding onto a stubborn cached redirect. This happens after site migrations, SSL changes, and domain changes. Clear Chrome’s site data first. If that fails, test with extensions off.

Pay attention to extensions that affect cookies, privacy, VPN routing, affiliate links, shopping coupons, or scripts. These tools can rewrite requests before the site sees them.

If both browsers fail

Now the problem is probably not your browser. The site itself may be misconfigured.

Site owners should check:

  • HTTP to HTTPS rules in the hosting panel and CMS.
  • WWW vs non-WWW rules in DNS, server config, and plugins.
  • Cloudflare SSL mode; “Flexible” SSL often causes loops when the origin also forces HTTPS.
  • WordPress redirect plugins, cache plugins, and security plugins.
  • Reverse proxy headers, especially X-Forwarded-Proto.
  • HSTS settings after switching domains or certificates.

Best practical workflow

Use this order to save time:

  1. Test the site in a private window.
  2. Clear data only for the affected domain.
  3. Try the other browser.
  4. Disable extensions or content blockers.
  5. Check VPN, Private Relay, and DNS filtering.
  6. If both browsers fail, inspect server redirects.

Bottom line: Safari is stricter and sometimes more sensitive, especially with cookies and privacy. Chrome is clearer and faster when you need proof of the redirect path. For everyday users, Safari’s targeted website data removal is the best first fix. For developers and site owners, Chrome’s Network tab is the tool that usually finds the real loop.

Related Posts