Chrome’s cache not clearing when you expect it to — pages still serving old content after hitting Clear Cache, images that should have updated looking identical to yesterday, or Chrome showing a version of a site that you know has changed — involves more layers than most people realise. The “clear cache” button in Chrome settings only clears one layer of a multi-level caching system. You’ll find the complete rundown in our Google Chrome Errors.
Hard refresh first: Ctrl+Shift+R (or Ctrl+F5). This bypasses Chrome’s cache for a single page load without touching any stored data. If the page looks correct after hard refresh but wrong on regular F5: Chrome’s standard cache has the stale content. The clear cache button will fix this permanently.
Actually clearing Chrome’s cache correctly
Ctrl+Shift+Delete → select “All time” in the time range dropdown → check “Cached images and files” → Clear data. Two important things: time range must be “All time” (not “Last hour” or “Last 7 days”), and the correct item must be checked. “Browsing history” is not cache. “Cookies” is not cache. “Cached images and files” is what you actually want cleared.
After clearing: do a hard refresh (Ctrl+Shift+R) on the page that was showing stale content. This combination — clearing the cache, then forcing a fresh load — reliably updates the content in most situations.
Service Workers — the cache that ignores the clear button
This is the most common reason “I cleared the cache but the site still shows old content.” Progressive Web Apps (PWAs) and modern websites install a Service Worker — a small JavaScript file that runs in the background and manages its own cache, independent of Chrome’s standard cache. Clearing Chrome’s cache does not clear Service Worker caches.
To clear Service Worker caches: open DevTools → F12 → Application tab → left sidebar → “Storage” → click “Clear site data” (includes service worker registration and caches). Or: Chrome Settings → Cookies and other site data → site → “Clear data.” This clears everything including service worker data.
Alternatively: Application tab → Service Workers (left sidebar) → click “Unregister” next to the site’s service worker → reload. This removes the service worker entirely, forcing the browser to fetch everything fresh from the server. The site reinstalls the service worker on next visit.
DNS and browser URL caching
Chrome maintains its own DNS cache (separate from Windows’ DNS cache) that maps domain names to IP addresses. If a site changed its server and Chrome is still sending requests to the old IP: content won’t reflect the new server’s files even after clearing browser cache.
Clear Chrome’s DNS cache: type chrome://net-internals/#dns in the address bar → “Clear host cache” button. Also clear sockets: chrome://net-internals/#sockets → “Flush socket pools.” These two clear Chrome’s internal network state without affecting Windows’ system-level DNS. After both: close and reopen Chrome for the cleanest state.
Extensions modifying cache behaviour
Caching extensions (cache managers, “speed boosters”) and some ad blockers maintain their own caches. If an extension is serving cached content: clearing Chrome’s cache doesn’t affect what the extension stored. Check: chrome://extensions → disable extensions related to caching or performance → test whether the site shows fresh content without them. If yes: that extension’s cache is the source of stale content. Look in the extension’s own settings for a “Clear cache” option, or uninstall it if you don’t need its function.
Our guide on Chrome page loading and rendering covers the related issues where pages load with broken elements rather than stale ones, and our Chrome cookies and site data covers clearing site-specific stored data that works alongside cache. For Service Worker development details and cache management, Chrome Developers documentation covers the Cache API and Service Worker lifecycle that govern how PWAs manage their offline content.
Server-side caching and CDNs
Sometimes the content is genuinely updated on the origin server, you’ve cleared every layer of Chrome’s cache, but you’re still seeing old content — because a CDN (Content Delivery Network) is serving cached files from an edge server that hasn’t received the update yet.
How to confirm: open DevTools → Network tab → reload the page → click on a specific file that’s showing old content → look at the Response Headers. If you see “X-Cache: HIT” or “Age: [large number]” headers: a CDN or proxy is serving a cached version, not the origin server. This is outside your control as a user. CDN caches typically expire within hours to days depending on configuration.
Workaround for testing: add a query string to the URL (e.g., add ?v=2 at the end). CDNs treat URLs with different query strings as different resources and fetch from origin. This is a developer debugging technique, not something end users should do routinely, but it confirms whether the CDN is the issue.
The cache-control headers matter
Whether Chrome caches something — and for how long — is determined by the server’s response headers. If a page sends Cache-Control: max-age=86400 (cache for 24 hours), Chrome won’t re-fetch it for a day regardless of whether you expect fresh content. Clearing cache removes the stored copy, but when you reload, Chrome can still return the same cached version if the server re-sends the same headers.
To see headers: DevTools → Network tab → reload → click a resource → Headers tab → look at Cache-Control, Expires, ETag, and Last-Modified. If Cache-Control says “no-cache” or “no-store”: the site doesn’t want the browser to cache. If it says “max-age=3600”: the browser is legitimately caching for an hour.
Clearing cache for a single site
Sometimes you want to clear cache for one specific site without affecting Chrome’s cache for everything else. Click the lock/info icon in the address bar → Cookies and site data → see how much data is stored → “Delete data.” This removes all cached content, cookies, and local storage for that domain only.
More directly from the keyboard: while on the site, DevTools → F12 → Application tab → Storage → select “Cache storage,” “Local Storage,” “Session Storage” individually → right-click → Clear. This gives granular control over exactly which type of stored data gets removed for the specific site.
IndexedDB — another cache layer
Web apps (Google Docs, Notion, various web apps) use IndexedDB to store data locally. IndexedDB is not cleared by the standard “Cached images and files” clear data option. It persists independently.
Clear IndexedDB: DevTools → Application tab → IndexedDB (left sidebar) → right-click each database → Clear database. Or: the “Clear site data” button under the Storage section clears everything including IndexedDB in one operation.
This is relevant when a web app shows incorrect data or seems to have cached state from an older session that isn’t reflecting server updates. Standard cache clearing misses IndexedDB entirely.
| Cache layer | Cleared by standard Clear button? | How to clear |
| HTTP cache (images, CSS, JS) | Yes | Ctrl+Shift+Delete → Cached images and files |
| Service Worker cache | No | DevTools → Application → Storage → Clear site data |
| IndexedDB | No | DevTools → Application → IndexedDB → clear database |
| Cookies | Only if selected explicitly | Ctrl+Shift+Delete → Cookies → check the box |
| Chrome DNS cache | No | chrome://net-internals/#dns → Clear host cache |
| CDN/server-side cache | No (not in your control) | Wait for expiry; or request server-side purge |
Most users need to clear the top three rows (HTTP cache, Service Worker cache, DNS cache) for a complete cache clear. The standard button only handles row one. The DevTools Application tab handles rows two and three. Knowing this prevents the frustrating loop of clearing cache and still seeing stale content.
Chrome profile cache vs browsing cache
Chrome’s profile stores cached data at %localappdata%GoogleChromeUser DataDefaultCache. The standard “clear cache” dialog clears this. But Chrome also maintains caches in other locations:
User DataDefaultCode Cache— JavaScript code cache for compiled scriptsUser DataDefaultGPUCache— GPU rendering cacheUser DataDefaultShaderCache— shader programs for GPU rendering
These are cleared when Chrome is closed and reopened after standard cache clearing, but sometimes they cause rendering issues that persist. Manual clear: close Chrome completely → navigate to the folder → delete the Cache, Code Cache, GPUCache, and ShaderCache folders → reopen Chrome. They’re recreated fresh on first launch.
This level of manual cache clearing is rarely needed but resolves some persistent visual glitches that survive standard cache clearing — particularly GPU rendering artifacts that look like parts of a page are stuck showing old versions of images or UI elements.
Keyboard shortcut reference for cache operations
Useful shortcuts worth knowing:
- F5: normal refresh — uses cache normally
- Ctrl+R: same as F5
- Ctrl+Shift+R: hard refresh — bypasses cache for this page load only (doesn’t clear cache)
- Ctrl+F5: same as hard refresh on most Windows systems
- Ctrl+Shift+Delete: opens the clear browsing data dialog
The distinction between hard refresh (Ctrl+Shift+R) and clear cache matters: hard refresh tells Chrome “don’t use cache for this single load” — the cached data is still there and regular F5 loads from it again. Clear cache actually removes the stored data. For most “stale content” situations, hard refresh is the instant fix; clear cache is needed when you want to ensure fresh content on every subsequent load too.
When to actually care about cache
Most users never need to manually clear Chrome’s cache at all. Chrome automatically expires cached content based on server-set cache headers, and the automatic cache management is well-tuned for normal browsing. Cache clearing is a troubleshooting tool — useful when:
- A site is broken and you want to rule out stale cached files
- A developer made changes that aren’t reflecting in your browser
- A site shows incorrect data that you know has been updated
- Chrome is misbehaving after an update and clearing state might help
As a routine practice: clearing cache “for performance” or “to make Chrome faster” is mostly a placebo. Chrome manages its cache efficiently; removing it just means it needs to re-download content on next visits. Cache isn’t a problem to solve on a regular schedule — it’s a tool to deploy when something specific is wrong.
Cache and Incognito mode
Incognito doesn’t cache anything permanently — each incognito session starts fresh and discards all cached data when the window closes. If stale content shows up in Incognito: the server or CDN is the source, not your browser cache. This is a useful diagnostic: same site, same problem in Incognito = server-side issue. Site works in Incognito, broken in normal Chrome = browser cache or extension issue.
Incognito also doesn’t use any cookies, which means authenticated content (logged-in pages) won’t work properly in Incognito unless you log in fresh within that session. This is worth knowing to avoid misattributing a login/session issue to a caching problem.
Understanding these layers makes cache clearing actually effective rather than just something you try when a site looks wrong. The key insight: Chrome’s “clear cache” button clears one specific layer, and modern web apps use several others that need separate clearing steps. The table above shows exactly which layer each clearing method addresses, which makes picking the right approach for each situation quick and deliberate.
For developers: network throttling and cache disabling
If you’re testing a site you’re developing and need Chrome to never use cache for any request: DevTools → Network tab → check “Disable cache” at the top. This bypasses all caching while DevTools is open. Close DevTools and Chrome returns to normal cache behaviour. Essential for web development; not relevant for regular users.
For testing Service Workers specifically: DevTools → Application → Service Workers → check “Bypass for network” → this makes Chrome ignore the Service Worker and fetch directly from the network. Combined with “Disable cache” in the Network tab: this gives you a completely fresh fetch every time while testing. Again, a developer tool — one-off use cases for testing, not a setting to leave on permanently.
Third-party proxy caches in corporate environments
Corporate networks often route web traffic through a proxy that maintains its own cache. When you clear Chrome’s browser cache: the proxy’s copy is unaffected, and the proxy serves its cached version to Chrome. From Chrome’s perspective, it correctly fetched fresh content; from the user’s perspective, it’s still showing old content because the proxy’s copy hasn’t updated.
Signs: cache clearing works at home but not at work. Or adding a query string to the URL breaks the “stale” behaviour (forces proxy to re-fetch). Proxy cache is IT-managed and typically expires automatically based on configured TTLs. If you need an immediate refresh from a specific site: contact IT with the URL and timestamp, and they can purge the proxy cache entry for that resource. This is a legitimate IT support request for corporate environments.
The practical takeaway: when Chrome’s cache still seems to be serving old content after a clear, the answer is almost never “clear harder.” It’s “which other cache layer is still serving stale content?” — and the Service Worker layer is the answer for most modern websites, the DNS layer for domain changes, and the CDN/proxy layer for corporate environments and widely-distributed sites. See also Chrome Dark Mode Not Working for a related case.
