Understanding the ERR_TOO_MANY_REDIRECTS error
The ERR_TOO_MANY_REDIRECTS notification appears in Chrome, Edge, and other Chromium-based browsers when a website keeps bouncing your request from one address to another without ever settling on a final destination. Most browsers will give up after roughly twenty redirect hops to protect your device from being stuck in an endless loading cycle. From the user's perspective, the page simply refuses to open, and the error code offers the only real clue about what is happening behind the scenes.
The underlying cause is almost always a misconfiguration somewhere in the chain of instructions that tells your browser where to go next. Sometimes the fault lies with the website itself, and sometimes it sits on your side of the connection. Understanding which is which can save you a frustrating call to your internet service provider or a wasted trip across town to test someone else's modem.
What this browser message actually means
A redirect is a simple instruction that says, in effect, "this page has moved, please go to that address instead." Websites use them routinely when they migrate to a new domain, switch from HTTP to HTTPS, or send mobile visitors to a streamlined version of their content. A loop forms when page A points to page B, page B points to page C, and page C points right back to page A, so the browser can never resolve where to actually stop.
To prevent your device from spinning its wheels forever, browsers impose a hard cap on how many redirects they will follow in a single chain. Chromium-based products trigger the error after about twenty attempts, while Firefox shows a slightly different message about the page not redirecting properly and caps the count at a similar threshold. The end result is the same: a broken page and a user left wondering whether the problem is theirs or someone else's.
Common triggers behind the loop
The most frequent culprit is an HTTPS misconfiguration, particularly after a site installs a new SSL certificate or switches hosting providers. If the server sends traffic to the secure version of a page, but the secure page then sends it back to the non-secure version, a loop is born. Cookie domain mismatches can produce a similar effect, especially on sites that set authentication cookies for one subdomain and then redirect to another that refuses to accept them.
Content management systems add their own layer of risk. A WordPress site with the site URL set to "www" but a redirect rule that strips the "www" prefix will ping-pong indefinitely. Reverse proxies and content delivery networks, which many Australian businesses use to speed up delivery to customers in Perth, Adelaide, and regional centres, can also introduce loops when their rules clash with the origin server's rules.
How Australian networks can contribute
Although the redirect loop itself is rarely caused by your internet service provider, the way Australian networks handle DNS and caching can occasionally make the problem look worse than it is. Major ISPs including Telstra, Optus, and TPG operate DNS resolvers that may cache older redirect records, meaning a fixed website can still appear broken for a while. Flushing your local DNS cache or switching to a public resolver like Cloudflare's 1.1.1.1 often clears this up.
Public Wi-Fi networks in cafés around Melbourne, Brisbane, or the Sydney CBD sometimes inject their own redirect rules to force a captive portal login page. If that portal is misconfigured, your browser can end up chasing its own tail before you ever see the sign-in screen. ACMA-mandated blocking of certain overseas gambling sites can also create chains that loop unexpectedly, particularly if a redirect passes through a filtered domain.
Clearing cookies and cache to break the cycle
Because authentication cookies are one of the common triggers, clearing them is usually the fastest fix you can try yourself. In Chrome, open the settings menu, choose Privacy and Security, then select Clear browsing data and tick the box for cookies. Firefox users will find the equivalent under Preferences, Privacy and Security, while Safari on a Mac hides the option under Develop, Empty Caches.
If you do not want to lose all your saved logins, try opening the same address in an incognito or private window first. Private sessions do not use existing cookies, so if the site loads there, the problem is almost certainly stored on your device. Mobile users on the train between Parramatta and the city can also test the page over their phone's 4G or 5G connection, which bypasses any local network oddities entirely.
When the problem sits on the server side
Sometimes no amount of clearing will help, because the redirect loop is hard-coded into the site's configuration. In that case, the only real fix is for the site owner to correct the conflicting rules on their server, load balancer, or CDN. Users can help by reporting the error to the site's support team, including the exact wording of the message and the time it occurred, which makes it easier for a developer to trace the problem in their logs.
A useful starting point for anyone responsible for a website is to check whether the SSL certificate is valid and properly installed, and to confirm that the canonical URL settings in the CMS match the redirect rules in the server configuration. For more general guidance on resolving browser-side issues, this troubleshooting resource walks through several common scenarios in plain language.
Related browser errors worth knowing
ERR_TOO_MANY_REDIRECTS is far from the only connectivity message you are likely to encounter. ERR_CONNECTION_TIMED_OUT appears when a server simply does not respond within the expected window, which can happen on flaky NBN connections during peak hours in suburbs with older fibre-to-the-node infrastructure. DNS_PROBE_FINISHED_NXDOMAIN signals that the domain name cannot be resolved, often because of a typo or a temporary outage at the registrar.
Each of these messages points to a different part of the connection chain, and learning to recognise them speeds up troubleshooting considerably. A separate guide on the ERR_CONNECTION_TIMED_OUT message explains the specific steps that tend to resolve timeouts, including router restarts and DNS changes. Keeping a mental catalogue of these codes makes you a more confident user the next time something refuses to load.
Browser-specific behaviour at a glance
Different browsers present the same underlying problem in slightly different ways, and some handle the underlying redirect count differently. The table below summarises the most common variations across the four browsers you are most likely to use in Australia.
| Browser | Error wording | Redirect cap | Quickest fix |
|---|---|---|---|
| Chrome | ERR_TOO_MANY_REDIRECTS | 20 | Clear cookies, try incognito |
| Edge | ERR_TOO_MANY_REDIRECTS | 20 | Clear cookies, try InPrivate |
| Firefox | The page isn't redirecting properly | 20 | Clear cookies, try private window |
| Safari | Safari Can't Open the Page | 16 | Clear website data, try private mode |
Most users will find that the fix is identical regardless of which browser they prefer, but knowing the wording helps when you are searching for advice or describing the issue to a support technician.
Steps that often resolve the loop in minutes
- Clear cookies and site data for the affected domain only
- Open the address in a private or incognito window to test
- Try the same URL on a different device or mobile network
- Flush your local DNS cache or switch to a public resolver
Habits that reduce the chance of hitting one again
- Keep your browser updated to the latest stable release
- Review bookmarked shortcuts after major site redesigns
- Avoid saving login sessions on shared or public computers
- Periodically clear old cookies you no longer need
If you have worked through the steps above and the page still refuses to load, the issue is almost certainly on the website's end and will require patience while their technical team resolves it. Setting a reminder to try again in an hour or two is often the most realistic course of action, as most loops are fixed quickly once they are reported. Bookmarking the address and returning later is generally a more productive use of your time than repeated refresh attempts, which can actually slow down the recovery process for other users on the same server.