Browser-side causes
The site is up, other people can use it, and your browser is showing you a broken version of it that it stored earlier. This is more common than any network fault.
The short version
- A private window tests cache, cookies and extensions simultaneously. Start there.
- Service workers can serve a stored broken page indefinitely, through ordinary reloads.
- Content blockers break sites when a filter list over-matches, which happens often.
- A stale cookie produces login loops that no amount of retrying will resolve.
When a site is broken for you and nobody else, the browser is the first place to look - And specifically the things the browser is keeping on your behalf. Caches, service workers, cookies and extensions all sit between you and the site, and each can independently produce a broken page from a perfectly healthy server.
Start with a private window
This is the highest-value single test available, because it disables four things at once: The HTTP cache, cookies and stored session data, service workers, and - In most browsers - Extensions.
If a site works in a private window and not in a normal one, you have confirmed the fault is local and narrowed it to one of those four. If it fails in both, none of them is the cause and you can stop looking here.
The HTTP cache
Browsers store responses to avoid re-downloading them, and mostly this is invisible and good. It becomes a problem when a site deploys a change and your browser keeps serving old files - A new HTML page loading an old JavaScript bundle produces a page that renders and does nothing.
A hard reload - Ctrl+Shift+R, or Cmd+Shift+R on a Mac - Bypasses the cache for that page and its resources. That is usually enough. Clearing the entire cache is rarely necessary and signs you out of a lot of things.
Service workers: The stubborn one
A service worker is a script the site installed in your browser that intercepts network requests and can answer them from its own storage. It is what makes web applications work offline, and it is why a normal reload sometimes changes nothing at all.
If a service worker cached a broken build, it will serve that broken build indefinitely. A standard refresh does not touch it. A hard reload usually bypasses it once but does not replace it.
To actually clear one: In Chrome or Edge, open DevTools (F12) → Application → Service Workers → Unregister. Then reload. In Firefox the equivalent is about:debugging#/runtime/this-firefox.
The non-technical route is "Clear site data" in the padlock menu next to the address bar, which removes everything for that one site and leaves the rest of your browser alone. That is almost always the right tool: Targeted rather than global.
Extensions
Content blockers are by far the most common culprit. They work by matching URLs against enormous filter lists, and when a site changes its CDN, its analytics provider or its asset domain, a list can over-match and block something the page actually needs.
The symptoms are distinctive: Missing images, buttons that do nothing, an infinite loading spinner, a video player that never initialises, or a login popup that fails to open.
Other regular offenders: Privacy extensions that strip parameters a site needs, password managers that interfere with form fields, script blockers, and "shopping helper" extensions that rewrite pages.
Testing is straightforward: Private window first, and if that fixes it, disable extensions one at a time. Most blockers also have a per-site pause, which is the pragmatic answer for a site you use regularly.
Cookies and stale sessions
A corrupted or expired session cookie produces one of the most frustrating failure modes there is: A login loop. You sign in successfully, you are redirected, the site does not recognise your session, and you land back at the sign-in page. Retrying cannot work, because the broken cookie is sent again every time.
Clearing cookies for that one site - Via the padlock menu, not globally - Resolves it. Signing out explicitly before signing back in does the same thing more gracefully when the site lets you.
The other cookie problem is a third-party one. Some sites depend on cookies from a separate authentication domain, and blocking third-party cookies breaks their sign-in flow. If a site fails to authenticate in a hardened browser and works in a default one, this is usually the reason.
Other local causes
The clock. A system clock that is significantly wrong makes valid TLS certificates look expired, breaking every HTTPS site at once. Certificate errors on every site means check the date before anything else.
The hosts file. An entry there overrides DNS entirely and persists through every cache clear. Some development tools and some ad blockers write to it.
A proxy setting. A proxy configured for something temporary and then forgotten, or left behind by software that has been uninstalled. If everything gives a connection error, check this.
Security software. Antivirus products with HTTPS scanning intercept TLS, and some of them do it badly. They cause connection resets and certificate warnings that look like network faults.
The order to work through
- Private window. Fixes it? Continue. Does not? Stop - The cause is not here.
- Hard reload in the normal window.
- Clear site data for that one site via the padlock menu.
- Unregister the service worker if the site is a web application.
- Disable extensions, or pause the content blocker for that site.
- Check the system clock.
- Try a different browser to confirm it is browser-specific rather than profile-specific.
What not to do: Clear all browsing data as a first move. It signs you out of everything, loses every session, and is almost never necessary - A per-site clear achieves the same thing without the collateral damage.
Questions people ask
Why does a website work in incognito but not normally?
Private windows start with no cache, no cookies, no service workers and usually no extensions. If a site works there, one of those four is the cause. Clearing site data for that single site through the padlock menu resolves most cases without signing you out of everything else.
What is a service worker and why does it break sites?
A script the site installed in your browser that intercepts requests and can answer them from its own storage. If it cached a broken version of the site it will keep serving that version, and an ordinary reload does not replace it - You have to unregister it or clear site data.
Can an ad blocker break a website?
Frequently. Blockers match URLs against large filter lists, and when a site changes CDN or analytics provider a list can over-match and block something the page needs. Missing images, dead buttons and infinite spinners are the usual symptoms.
Why do I keep getting logged out or sent back to the login page?
Almost always a stale or corrupted session cookie. Signing in succeeds, the site does not recognise the resulting session, and you are bounced back - And retrying resends the same broken cookie. Clearing cookies for that one site fixes it.
Read next
Clearing the DNS cache
Exact commands for flushing the DNS cache on every major platform, plus the browser and router caches people forget about.
Is it down for everyone, or just you?
A practical order of tests for working out whether a website is genuinely down or the problem is on your side - And what each result rules out.
VPN and proxy problems
Why VPNs cause 403 errors, captcha loops, slow connections and half-loading pages - And how to identify which of those you have.
Is it my internet, or the website?
A layered diagnostic for working out whether the fault is your device, your network, your ISP, DNS, or the website itself.