Diagnose Chrome-only page failures: cache-busting, clear site data, remove service workers, purge CDN and reset…
Join developers getting comprehensive guides, code examples, optimization tips, and time-saving prompts to accelerate their development workflow.
No spam. Unsubscribe anytime.
A page that misbehaves only in Chrome, while working fine in another browser, on another device, or through an external testing tool, usually points to something Chrome is holding onto rather than a bug in the page itself: corrupted cache data, an outdated redirect, stale DNS information, a leftover service worker, or a cached response from a proxy or CDN. The fastest way to confirm this is a cache-busting query parameter on the URL, and if that fixes the page, the rest of the fix is about clearing the right cache rather than touching code.
I run into this constantly across client sites with CDNs, service workers, and aggressive edge caching, and it always starts the same way: a client reports a broken page, I open it fine in Firefox or an incognito window, and Chrome alone shows the stale version. Here's the exact sequence I use to confirm it's a caching issue and clear it.
Add a temporary query parameter to the affected URL:
https://example.com/problem-page/?test=1
This changes the URL enough that Chrome treats it as a new request instead of serving a cached response. If the page suddenly renders correctly, stale or corrupted cache data is almost certainly the cause, and you can move straight to clearing it instead of digging through the page's code.
A handful of fixes work through most cases, roughly in order of how disruptive they are:
To clear data for one site specifically, open Chrome settings, search for the domain under stored site data, and remove it. Chrome DevTools offers a faster path for this during active debugging: open the Application panel, go to Storage, and select Clear site data.
If the issue only shows up on one route, test both versions of the URL, since Chrome and some CDNs can cache them separately:
/example-page
/example-page/
A cache-busting parameter works here too:
/example-page/?refresh=1
If that query parameter clears the problem, the next step is usually clearing the relevant browser cache or purging the cached page directly from your CDN or hosting platform, since the stale copy is often sitting at that layer rather than in Chrome alone.
Before assuming the website itself is broken, compare the page across normal Chrome, Incognito mode, another browser, another device, another network, and the same URL with a cache-busting query parameter. Six quick checks like this can save hours of debugging code that was never the problem.
Each browser keeps its own cache, service worker registrations, and DNS resolver cache. Chrome tends to cache aggressively and hold onto service workers longer than some other browsers, so a stale response can persist in Chrome well after a CDN or origin server has already updated.
Mostly, but not completely. Incognito skips your existing cache and cookies, but it can still hit a cached response sitting at a CDN or proxy layer, so a correct result in Incognito narrows the problem to Chrome's local cache rather than ruling out caching entirely.
A hard reload clears the cache for that page load only. Clearing site data through Chrome settings or DevTools removes cookies, local storage, service workers, and cached responses for the entire domain, which matters when a service worker is the actual culprit.
If the cache-busting query parameter fixes the page in Chrome but the original URL still fails after clearing Chrome's cache and testing in Incognito, the stale response is most likely sitting at the CDN or proxy layer and needs to be purged there directly.
No. That defeats the purpose of caching and can hurt performance across your whole site. Use the query parameter only as a diagnostic step, then fix the actual cache configuration, service worker logic, or CDN purge behaviour causing the staleness.
A page that only breaks in Chrome is rarely a code problem. Confirming it with a cache-busting query parameter, then working through Chrome's site data, DNS cache, and any CDN or service worker involved, resolves most of these cases without touching a single line of application code. Let me know in the comments if you've run into a caching issue this didn't catch, and subscribe for more practical debugging guides.
Thanks, Matija