What Is a Service Worker?

A service worker is a script that the browser registers for a website and then runs separately from any page. It has no access to the DOM and cannot touch the page directly. Instead it listens for events: network fetches, push messages, sync triggers, and lifecycle events like install and activate.

The defining feature is that it acts as a proxy for outgoing network requests from pages under its scope. Once registered and active, every fetch the page makes (HTML, CSS, images, API calls) passes through the service worker's fetch event handler first. The handler decides whether to answer from a cache, go to the network, or build a response on the fly.

Service workers only run over HTTPS (localhost is exempted for development). That requirement exists because a script that can rewrite every response on a site would be a serious attack vector over plain HTTP. They are the technical foundation of Progressive Web Apps, the thing that lets a website install to a home screen and work offline like a native app.

Reach for a service worker when offline support, instant repeat loads, push notifications, or background sync genuinely improve the product. News apps, email clients, maps, and document editors all benefit. If a site is a simple static page that loads fine from the CDN, a service worker adds complexity for little gain.

The biggest trap is caching the worker or its assets too aggressively and shipping a stale version that users cannot escape. A bad service worker can serve old broken code to returning visitors for as long as the cache lives. Always version your caches, clean up old ones on activate, and set the worker script itself to a short or no-cache HTTP header so updates are picked up.

Debugging is harder than normal page code because the worker runs in its own context and outlives the page. The waiting-and-activation lifecycle confuses people the first time. Use the Application panel in Chrome DevTools to inspect registration, caches, and force updates. Build tools like Workbox generate the routing and lifecycle boilerplate so you write strategies instead of raw event plumbing.

sw.js is simply the name most tutorials give the service worker file, including MDN's examples. Any file name works. What matters is where the file lives, because a service worker controls only the URLs in its own folder by default. A worker at /js/sw.js controls pages under /js/ and nothing else, which is why most sites serve it from the root. You can set a narrower scope when you call navigator.serviceWorker.register, and a wider one needs the Service-Worker-Allowed response header.

Browsers check for a new version of the file on their own. A check happens when the user navigates to a page in the worker's scope, and on events such as push and sync unless a check already ran in the previous 24 hours. If the downloaded file differs by even one byte, the browser installs it as an update. Most browsers, including Chrome 68 and later, ignore HTTP caching headers when they check the worker file, and the updateViaCache option of register changes that. See HTTP caching for how the other files are cached.

The W3C specification defines a service worker as a worker that wakes to receive events. MDN lists three kinds of worker on the web: dedicated workers, used by a single script; shared workers, used by several windows or iframes on one domain; and service workers, which sit as a proxy between the web app, the browser, and the network. Only service workers can intercept requests and keep a site working offline.

In system design interviews, a worker usually means a server-side process instead. It pulls jobs from a message queue and runs them in the background, like the workers in a distributed job scheduler. The worker process page explains server workers, and workers vs threads, in full. Both run apart from the code that answers the user directly, but one lives in the browser and the other on your servers. The Progressive Web Apps lesson shows how service workers make a site installable.