Service Worker

Updated September 30, 20262 min read

In short

A service worker is a script the browser runs in the background, apart from the page, to intercept network requests and enable offline use and push messages.

What is a service worker?

A service worker is a special JavaScript file that the browser runs in the background, separate from any web page. It sits between your web app and the network like a programmable proxy: every request the page makes, for HTML, scripts, images, or API data, can pass through it, and the service worker decides whether to answer from a cache, go to the network, or combine both.

A page registers a service worker with navigator.serviceWorker.register(), and the browser then takes it through a lifecycle of installing, waiting, and activating. The worker reacts to events such as install, where it usually pre-caches important files, fetch, where it handles requests, and push, where it can show a notification. Service workers have no access to the DOM, run only over HTTPS (or on localhost during development), and are stopped by the browser when idle and restarted when a new event arrives.

Think of an assistant who screens your mail: some letters are answered right away from a filing cabinet, and only the rest are passed on to you. Service workers are the core technology behind progressive web apps, making offline pages, faster repeat visits, background sync, and web push notifications possible.

A service worker is often confused with a web worker. Both run JavaScript off the main thread, but a web worker belongs to one page and is used for heavy calculations, while a service worker controls every page in its scope, intercepts network traffic, and can keep running after the tab is closed. Because a buggy service worker can keep serving outdated files, updates need care, for example versioning cache names and deleting old caches when the new worker activates.

Key takeaways

A service worker is a background script that can intercept a site's network requests.
It enables offline support, caching strategies, push notifications, and background sync.
It has no DOM access and requires HTTPS, except on localhost.
It goes through install, waiting, and activate phases before it controls pages.
Unlike a web worker, it controls every page in its scope, not just one.

Example

A cache-first service workerjavascript

// main.js: register the service worker
navigator.serviceWorker.register("/sw.js");

// sw.js: pre-cache key files, then answer requests from the cache first
self.addEventListener("install", (event) => {
  event.waitUntil(caches.open("v1").then((c) => c.addAll(["/", "/app.css"])));
});

self.addEventListener("fetch", (event) => {
  event.respondWith(
    caches.match(event.request).then((cached) => cached || fetch(event.request))
  );
});

Readers ask

What is the difference between a service worker and a web worker?

A web worker runs heavy JavaScript in the background for a single page. A service worker acts as a network proxy for every page in its scope, can answer requests from a cache, and can receive push messages even when the site isn't open.

Do service workers work offline?

Yes, that is one of their main uses. Once the service worker has cached the files a page needs, it can serve them without a network connection, so the site still loads offline.

Why is my service worker not updating?

A new service worker installs but then waits until every tab controlled by the old one is closed, so a simple reload often isn't enough. Calling self.skipWaiting() in the new worker makes it activate right away, and browser developer tools offer an update-on-reload option for testing.