🛡️ Service Worker Generator
Generate a service worker (sw.js) online — precache list, runtime cache strategies (cache-first, network-first, stale-while-revalidate), navigation fallback, registration snippet
One URL per line. These are fetched and stored when the service worker installs, so the app works offline immediately.
Match requests by URL pattern (a regex string, e.g. /api/ or \.css$) and cache them with a strategy.
When a navigation request fails (offline), serve this URL from cache instead.
Bump this to invalidate all caches on the next deploy.
Registration snippet (in your HTML)
About this tool
A service worker is a JavaScript file that runs in the background and lets your website work offline, load faster on repeat visits, and qualify as an installable PWA. This generator produces a ready-to-use sw.js from a simple form — no libraries, no build step, just vanilla Service Worker API code you can read and edit.
Configure two things: a precache list (URLs fetched and cached when the worker installs, so the app is instantly available offline) and runtime cache rules that match requests by URL pattern and apply a caching strategy. The three main strategies cover most cases: cache-first for static assets (CSS, JS, fonts — serve from cache, fetch only if missing), network-first for fresh data (API calls — try the network, fall back to cache when offline), and stale-while-revalidate for assets that update (serve cached immediately, refresh in the background).
Example: precache /, /index.html, /styles.css; add a rule matching /\.css$/ with stale-while-revalidate and another matching /api/ with network-first. The generator outputs the full sw.js plus a registration snippet to paste in your HTML.
FAQ
Where do I put the generated sw.js file? ›
Save the output as sw.js in your site root (or any directory). Serve it from the same origin as your pages. Then add the registration snippet to your HTML. The service worker only controls pages within its scope (the directory it lives in and below).
What is the difference between precache and runtime cache? ›
Precaching stores a fixed list of URLs when the service worker installs — these are available offline immediately. Runtime caching stores responses on-the-fly as users browse, using rules you define (which URLs to cache and how). Precache is for your app shell; runtime is for dynamic content and assets.
When should I use cache-first vs network-first vs stale-while-revalidate? ›
Cache-first is best for static assets that rarely change (fonts, icons, bundled JS). Network-first is for data that should be fresh but needs an offline fallback (API responses, news feeds). Stale-while-revalidate gives instant loads while updating in the background — good for CSS/JS that changes between deploys.
Why do I need to bump the cache version? ›
Browsers keep old cache entries until explicitly deleted. When you deploy new precached files, increment the version prefix (e.g. v1 to v2) so the new service worker creates fresh caches and the activate event deletes the old ones. Without this, users may see stale content.