chrome://settings/content/all, find the site, and click Clear data — or use DevTools (F12 > Application > Cache Storage > right-click > Delete). The Clear Cache extension handles this automatically when you select "All site data."
- What Is a Service Worker?
- Service Worker Cache vs. Browser HTTP Cache
- How Service Worker Cache Gets Populated
- Why Service Worker Cache Causes "Cache Clear Didn't Work" Problems
- How to Clear Service Worker Cache
- Service Worker Caching Strategies
- Service Workers and PWAs
- Service Worker Lifecycle: Why Updates Sometimes Fail
- Checking if a Site Has a Service Worker
- Developer Perspective: Avoiding Service Worker Cache Problems
- Summary: Service Worker Cache Quick Reference
- Frequently Asked Questions
- What Is a Service Worker?
- Service Worker Cache vs. Browser HTTP Cache
- How Service Worker Cache Gets Populated
- Why Service Worker Cache Causes "Cache Clear Didn't Work" Problems
- How to Clear Service Worker Cache
- Service Worker Caching Strategies
- Service Workers and PWAs
- Service Worker Lifecycle: Why Updates Sometimes Fail
- Checking if a Site Has a Service Worker
- Developer Perspective: Avoiding Service Worker Cache Problems
- Summary: Service Worker Cache Quick Reference
- Frequently Asked Questions
You cleared the cache. You refreshed the page. The site is still showing outdated content. Sound familiar? In many cases, the culprit isn't the HTTP cache at all — it's the service worker cache, a completely separate storage system that most cache-clearing guides don't mention. This article explains what service worker cache is, why it exists, why it's different, and exactly how to clear it when it's causing problems.
Clear Service Worker Cache Without DevTools
The Clear Cache extension clears all site data — including service worker cache — directly from your toolbar. No DevTools required.
Add to Chrome — FreeWhat Is a Service Worker?
A service worker is a JavaScript file that runs in the background of your browser, separate from the web page itself. It acts as a network proxy — it can intercept requests your browser makes and decide whether to serve a cached response, fetch from the network, or do something in between.
Service workers were introduced to enable Progressive Web Apps (PWAs) — web applications that work offline, load instantly, and behave like native apps. Google Docs, Twitter, Facebook, Gmail, Spotify Web, and thousands of other modern sites register service workers.
The key concept: a service worker runs even when the page is closed. It persists in the background and handles caching logic independently from the page's JavaScript.
Service Worker Cache vs. Browser HTTP Cache
These two caching systems coexist in your browser and are entirely independent:
| Feature | HTTP Cache (Browser Cache) | Service Worker Cache |
|---|---|---|
| Who controls it | Browser (based on HTTP headers) | The website's JavaScript code |
| What it stores | HTTP responses (HTML, CSS, JS, images) | Whatever the developer chooses |
| Cleared by Ctrl+Shift+Delete | Yes | No |
| Cleared by hard refresh (Ctrl+Shift+R) | Yes (for the current page) | No |
| Cleared by "All site data" in Chrome settings | Yes | Yes |
| Access from DevTools | Network tab → disable cache | Application tab → Cache Storage |
| Can work offline | No (requires network for new requests) | Yes (can serve from cache with no network) |
| Update mechanism | Cache-Control headers expire it | Developer code updates it |
This table explains why clearing cache "the normal way" doesn't always work: the standard cache clear only touches the HTTP cache. The service worker cache is untouched and continues serving its stale version.
How Service Worker Cache Gets Populated
When you first visit a site with a service worker, the browser downloads the service worker file and runs it. The service worker then decides what to cache during its "install" phase. This is called precaching — pre-downloading resources the app needs to function offline.
For a typical PWA, this might include:
- The app shell HTML (the skeleton layout)
- Core JavaScript bundles
- CSS stylesheets
- Fonts and icons
- API responses that don't change often
This is stored in the Cache Storage API — a key-value store separate from HTTP cache, IndexedDB, and localStorage. You can see exactly what's stored there in Chrome DevTools (F12 → Application → Cache Storage).
workbox-precache-v2-https://example.com/ or static-assets-v3) is a separate service worker cache bucket. Click any cache to see exactly what's stored and the size of each entry.
Why Service Worker Cache Causes "Cache Clear Didn't Work" Problems
The typical scenario: a developer pushes an update to their website. Users who visited the site before have a service worker installed that's still serving the old version. Even after those users clear their browser cache, the service worker intercepts requests and serves its cached old version — bypassing the network entirely.
This creates several specific problems:
Problem 1: Site Shows Old Content After Update
You cleared cache, refreshed, but the site still looks like it did a week ago. The service worker's precached files haven't been updated. The developer may have forgotten to increment the service worker version, or the update mechanism isn't working correctly.
Problem 2: "Offline" Mode Persists When Online
Some sites show an offline fallback page when the service worker can't connect to the network. If the service worker itself is broken or stuck in a bad state, it might keep serving the offline fallback even when you have a working internet connection.
Problem 3: JavaScript Errors on Modern Site
A service worker might be serving an old cached version of a JavaScript file that's incompatible with a new server API. This causes errors that look like JavaScript bugs but are actually cache inconsistency issues.
Problem 4: PWA Won't Update After Install
Installed PWAs (apps added to your taskbar or home screen via Chrome) use service workers heavily. If the service worker isn't updating, the installed app stays on the old version indefinitely.
One-Click Service Worker Cache Clear
Clear all site data — including service worker caches — for any site you're browsing. No DevTools, no digging through Chrome settings.
Install Clear Cache — FreeHow to Clear Service Worker Cache
Method 1: Chrome Settings (Recommended for Most Users)
chrome://settings/content/all in your address bar. This shows all sites that have stored data in Chrome.
Method 2: Chrome DevTools (More Surgical)
Method 3: Clear Cache Extension (Easiest)
If you're on the affected site, clicking the Clear Cache extension icon and selecting "All site data" (or the most thorough clearing option) handles service worker cache along with all other storage types. This is the fastest approach if you're not a developer who needs to inspect what's being cleared.
Method 4: chrome://serviceworker-internals
chrome://serviceworker-internals in Chrome. This shows ALL registered service workers across all sites.
Service Worker Caching Strategies
Understanding why a site might serve stale content requires knowing the different strategies developers use:
| Strategy | How It Works | When You See Stale Content |
|---|---|---|
| Cache First | Serve from cache, use network as fallback | Always serves cached version until cache is cleared or expires |
| Network First | Try network, fall back to cache if offline | Only if network fails or takes too long |
| Stale While Revalidate | Serve cache immediately, fetch update in background | On first visit after an update (second visit is fresh) |
| Cache Only | Only serve from cache, never use network | Always — until cache is manually updated |
| Network Only | Always use network, never cache | Never (defeats offline purpose) |
The most common cause of "clearing cache didn't work" is a Cache First strategy where the service worker was built to serve from cache aggressively for performance, without a proper update mechanism. Or a Stale While Revalidate situation where the background revalidation fetch is failing silently.
Service Workers and PWAs
Progressive Web Apps (PWAs) — websites installed as apps via "Add to Home Screen" or the install icon in Chrome's address bar — rely entirely on service workers to function offline. The service worker is what makes a PWA feel like a native app.
PWAs typically use a library called Workbox (by Google) to manage their service worker caching. Workbox generates cache names like workbox-precache-v2-https://app.example.com/. If you see these in Cache Storage, you're dealing with a Workbox-managed PWA. These update reliably — if the content is stale, there's likely a genuine caching bug in the app.
Service Worker Lifecycle: Why Updates Sometimes Fail
The service worker update process has a specific lifecycle that can cause updates to appear stuck:
- Browser detects a changed service worker file (checks every 24 hours, or on every navigation if the page opts in)
- New service worker downloads and installs (in parallel with the existing one)
- New service worker enters "waiting" state — it can't activate until all pages using the old service worker are closed
- User closes all tabs for that site
- New service worker activates, deletes old caches, populates new ones
The stuck point is almost always step 3: the new service worker is waiting, but the user never closes all tabs for that site. This is why Chrome DevTools shows "waiting to activate" for new service workers. To force activation, close all tabs for that site, then reopen it.
Checking if a Site Has a Service Worker
You don't have to guess whether a site uses a service worker. Here's how to check:
Most major websites you use daily have service workers: Google Workspace apps, Twitter/X, Facebook, Instagram, Spotify, Notion, LinkedIn, and thousands more. If a site works offline or loads extremely fast on repeat visits, it almost certainly uses a service worker.
Clear All Site Data in One Click
Stop digging through Chrome settings every time a site gets stuck. Clear Cache handles HTTP cache, service worker cache, IndexedDB, cookies, and localStorage — for any specific site you're on.
Add to Chrome — FreeDeveloper Perspective: Avoiding Service Worker Cache Problems
If you're a developer building sites with service workers, several practices prevent the "users stuck on old version" problem:
- Use content hashing for cached file names —
app.a1b2c3d4.jsforces cache invalidation when file content changes - Increment your cache version names — Change
static-v1tostatic-v2when assets change; the old service worker will detect the new version - Don't cache the service worker file itself aggressively — The
sw.jsfile should be served withCache-Control: no-cacheso the browser always checks for updates - Implement a "refresh to update" UI prompt — When a new service worker is waiting, show users a "Update available — click to refresh" banner
- Use Workbox — Google's Workbox library handles all of this automatically, including cache versioning and update prompts
Summary: Service Worker Cache Quick Reference
| Action | Clears HTTP Cache? | Clears Service Worker Cache? |
|---|---|---|
| Ctrl+Shift+Delete → Clear browsing data | Yes | No |
| Hard refresh (Ctrl+Shift+R) | Yes (current page) | No |
| Incognito mode | Irrelevant (fresh session) | No (SW still runs) |
| chrome://settings/content/all → Clear data | Yes | Yes |
| DevTools → Application → Unregister SW + Delete caches | No | Yes |
| Clear Cache extension → All site data | Yes | Yes |
| Closing all tabs for the site (update lifecycle) | No | Allows new SW to activate |
Frequently Asked Questions
What is service worker cache and how is it different from browser cache?
Service worker cache is a JavaScript-controlled storage layer managed by website code, completely separate from the browser's HTTP cache. The HTTP cache is controlled by browser headers and cleared with Ctrl+Shift+Delete. Service worker cache is controlled by app JavaScript and requires going to chrome://settings/content/all or using DevTools to clear. The key distinction: standard cache clearing often doesn't touch service worker cache at all.
Why does clearing cache not fix my problem if the site uses a service worker?
Because the service worker intercepts network requests and serves its own cached response — bypassing both the network and the HTTP cache. When you clear the HTTP cache, the service worker still has its own cache intact and keeps serving from it. To fix this, you need to clear all site data (which includes service worker cache) from chrome://settings/content/all, or use DevTools to manually delete the Cache Storage entries and unregister the service worker.
Will clearing service worker cache delete my app data or offline content?
Clearing service worker cache removes the locally cached app assets (JavaScript, CSS, HTML) that enable offline access. Your actual account data, documents, and server-stored content won't be deleted. However, the app will lose offline functionality temporarily — until it reconnects to the internet and re-downloads its assets. For PWAs like installed Google Docs or Twitter, offline mode will stop working until the next time you open the app while connected.
How do I know if a website is using a service worker?
Open Chrome DevTools (F12) → Application → Service Workers. If entries appear, the site has an active service worker. Also check Application → Cache Storage — named caches (especially ones starting with "workbox-") confirm service worker caching is active. Most modern web apps and all PWAs use service workers, including Google Workspace apps, Twitter, Facebook, Spotify, and Notion.
Can a service worker cache be updated without clearing it?
Yes — service workers have a built-in update mechanism. When the developer changes their service worker file, Chrome detects the change, downloads the new worker, installs it, and activates it once all old tabs for that site are closed. The new service worker can delete old caches and populate fresh ones. If a site isn't updating, it's usually because all tabs for that site were never fully closed, or the service worker file is being cached aggressively by the HTTP cache itself.
What is a stale-while-revalidate service worker strategy?
Stale-while-revalidate serves the cached version immediately (fast) while fetching a fresh version in the background. On your next visit, you see the updated version. This is why sites sometimes look "one update behind" — you're seeing last visit's version while the new version is being fetched. If a site is always showing old content rather than just one-version-behind, the background revalidation is likely failing, and clearing all site data will force a complete fresh load.
Why does a site work in Incognito but show old content in regular mode?
Incognito mode starts with a fresh session — no existing cookies, localStorage, or IndexedDB — but it does still run service workers if they were registered in normal mode. However, in Incognito, the service worker runs in an isolated context and typically won't have the same cached data as your regular session. If the site works in Incognito but not regular mode, it could be a service worker issue, an IndexedDB corruption, or a conflicting extension. Start by clearing all site data for that domain in regular mode.
More Free Chrome Tools by Peak Productivity
