Why a site works in Incognito but not your normal browser

A private window is not a different computer. It shares your DNS, your network, your operating system and your IP address. It differs in exactly four ways, and when a site works there but not in your normal profile, one of those four is responsible.

This test is worth running early because of what it rules out. Same machine, same network, same route to the same server: the site is up, your network is fine, and the fault is inside your browser profile.

What Incognito actually changes ¶

• Cookies and site data start empty and are discarded on close.
• Extensions are disabled by default.
• Service workers from your normal profile do not apply.
• The HTTP cache is separate, including cached redirects.

Everything else is shared. That is why "it works in Incognito" is such a precise signal.

1. A stale service worker serving a dead page ¶

The one people miss. A service worker is a script the site installed in your browser that can intercept every request and answer from its own cache without touching the network. When a site ships a broken one, or you have an old version from before a migration, the page can fail identically forever while the server is perfectly healthy.

In Chrome, open chrome://serviceworker-internals, or DevTools, Application, Service Workers, and unregister the one for that origin. In Firefox, about:debugging#/runtime/this-firefox. Reload afterwards.

The tell: the page loads instantly and wrongly, rather than slowly and then failing. Nothing that fast touched a network.

2. A cached permanent redirect ¶

A 301 is, by definition, permanent, and browsers cache it aggressively, sometimes indefinitely. If a site ever served a 301 to a URL that is now wrong, your browser will keep following it without asking the server again. Incognito has no such cache, so it goes straight to the real destination.

Clearing site data for that origin fixes it. You can see what the server sends today, as opposed to what your browser remembers, with our redirect tracer.

3. An extension ¶

Content blockers, privacy tools, script managers, corporate security extensions and password managers all modify requests. A blocked analytics domain the site loads synchronously, a stripped header, an altered user agent: any of these can break a page while leaving no visible error.

Do not disable them one at a time from the top. Disable all, confirm the page loads, then re-enable in halves. Two or three reloads finds the culprit; going one by one takes a dozen.

4. A corrupted or stale cookie ¶

Session cookies that reference an expired server-side session, an old authentication token, or a cookie set for the wrong domain scope commonly produce a redirect loop or a hard 403. The server is answering correctly; it is answering the question your cookie is asking.

A redirect loop between a site and its login page is the classic signature. So is a 403 Forbidden that appears for you and nobody else. Clear cookies for that origin specifically rather than wiping everything.

When Incognito does not help ¶

If a site fails in a private window too, the browser profile is exonerated and the problem is further out: DNS, the network path, or the site itself. Run a multi-method check next. If all four probes reach the site, the fault is between you and it, and the Wi-Fi versus mobile data test is the fastest way to narrow it down.

The thirty-second version ¶

1. Private window. Works? The fault is in your profile. Continue.
2. Instant wrong page rather than a slow failure? Service worker or cached redirect.
3. Redirect loop or a 403 only you get? Cookies.
4. Neither? Disable extensions, confirm, then bisect.

Browser differences worth knowing ¶

Private mode is not identical across browsers, and the gaps matter when you are using it as a test.

• Chrome and Edge: extensions are off unless individually allowed in private windows. Check that none has been allowed, or your test is not clean.
• Firefox: extensions run in private windows by default unless you say otherwise, so a private window does not rule them out. Use a fresh profile instead: firefox -P.
• Safari: private tabs share less than you might expect, but content blockers still apply system-wide on iOS.

HSTS state is also shared in most browsers. If a site is stuck upgrading to HTTPS against a server that no longer speaks it, a private window will not help, and the fix is to clear the HSTS entry specifically rather than the cache.

Capture the evidence before you clear it ¶

Clearing site data destroys the thing that would have explained the fault, and the fault usually does not come back on demand. Thirty seconds of capture first:

1. DevTools, Network tab, reload with "Preserve log" on. Screenshot the failing request, its status, and its timing.
2. Note whether the failing response came (from ServiceWorker) or (from disk cache). Chrome labels both in the Size column, and either label ends the investigation immediately.
3. Copy the failing request as cURL, right-click the request, Copy, Copy as cURL. Running that in a terminal takes the browser profile out of the picture entirely: if it succeeds there, the profile is confirmed as the cause.

That last step is the cleanest version of the whole test, and it is worth reaching for first if you are comfortable in a terminal.