Chrome Showing an Old Version of a Website? 5 Places the Old Copy Hides

Chrome showing an old version of a website is one of the strangest feelings on the web. The update is live. Your coworker sees it. Your phone sees it. Your laptop insists it is still last Tuesday.

It is not a bug. Chrome is doing its job: reusing a saved copy so pages load fast. The trick is finding which saved copy, because there are five places one can hide, and a normal refresh only reaches one of them.

The short answer#

• Hard refresh first: Ctrl+Shift+R, or Command+Shift+R on a Mac.
• Still old? A service worker is probably serving it. Clear that site's data, which removes the worker.
• Test in Incognito. If it is new there, the old copy is in your browser. If it is old there too, it is in the CDN or on the server.
• Running the site? Version your file names and set short cache rules on HTML.

Is Chrome showing an old version, or is the site? The Incognito test#

Before you change anything, open an Incognito window (Ctrl+Shift+N, or Command+Shift+N on a Mac) and load the same page.

• New version in Incognito: the old copy is stored in your normal profile. It is in places 1, 2 or 3 below. You can fix it in your browser.
• Old version in Incognito too: your browser is not the problem. It is a CDN or server cache, places 4 and 5. Clearing your data will not help.

That single test tells you where to look.

1. The browser cache#

Chrome keeps copies of files, such as images, scripts and style sheets, as long as the site's cache rules allow. If a new HTML page asks for app.js and Chrome already has an app.js it believes is fresh, it may use the old one. The result is a page that looks half old, half new, or just broken.

Fix: a hard refresh. Press Ctrl+Shift+R on Windows and Linux, or Command+Shift+R on a Mac. This fetches every file again for that load. Our hard refresh guide covers all the shortcuts and the stronger Empty Cache and Hard Reload option.

2. A service worker#

This is the one that fools people. Many modern sites and web apps install a service worker: a small script that sits between the page and the network and can answer requests from its own stored copy. MDN describes it as acting like a proxy between the app, the browser and the network.

When a site updates, the new service worker often waits until every tab of the site is closed before it takes over. Until then, the old worker keeps serving the old app. Refresh all you like.

Fix:

1. Close every tab of the site, then open it again. Sometimes this is enough.
2. If not, clear the site's data, which removes the worker. Open DevTools (F12, or Command+Option+I), go to Application, then Storage, untick Cookies to stay signed in, and click Clear site data.

Or use Cleaner, our free Chrome extension. Its Fix broken page button clears the current site's cache and service workers in one click, keeps your cookies so you stay signed in, and reloads the page.

3. Site storage#

Some apps store content or settings in local storage or IndexedDB: the last version you saw, a cached feed, a feature switch. No reload clears these. If an app shows old content even after the service worker is gone, its stored data is the next suspect.

Fix: clear site data for that one site, leaving all storage boxes ticked. In DevTools, the Application panel lists each storage type, so you can see what the site saved first. Our DevTools clear site data guide walks through it.

4. A CDN#

Most sites sit behind a content delivery network that keeps copies of pages close to visitors. If the CDN still holds the old page, every new visitor in your region gets it, including in Incognito.

Fix (visitor): wait. CDN copies expire, often within minutes or hours. Fix (site owner): purge the CDN cache for the changed pages.

5. The server's own cache#

Content systems such as WordPress often cache full pages on the server through a plugin or the host. The CDN and your browser are both faithfully delivering a stale page the server itself built earlier.

Fix (site owner): clear the page cache in your CMS or hosting dashboard after publishing.

A quick checklist to work through#

Notice that none of these needs Chrome's Delete browsing data button. Clearing every site's data to see one site's update signs you out of everything for no reason. If you do want the wider options, our guide on how to clear cache in Chrome covers them.

If you run the site: make old versions impossible#

Developers hit this more than anyone. A few habits remove most of it:

• Version file names. Build tools can name files by content, such as app.3f9a1.js. A new deploy means new names, and no browser can reuse an old file.
• Short cache rules on HTML. Let HTML revalidate on every visit and cache the versioned files for a long time. MDN's HTTP caching guide explains Cache-Control for both.
• Update service workers on purpose. Show an "update available, reload" prompt when a new worker is waiting, instead of leaving users on the old one.
• During development, tick Disable cache in the DevTools Network panel and Update on reload under Application, then Service workers.

Bottom line#

When Chrome shows an old version, run the Incognito test, then work from the browser cache to the service worker to site storage. Clear one site, not the whole browser. In most cases the old copy is gone within a minute, and you never had to sign out of anything.