What can service workers do that web workers cannot?

Buksy's answer is correct but in my opinion it does not answer the original question, namely: "What can service workers do that web workers cannot? Or vice versa?"

There are fundamental differences in their lifecycle and the number of instances per origin you can have. In short:

               | Web Workers  | Service Workers  |
|--------------|--------------|------------------|
| Instances    | Many per tab | One for all tabs |
| Lifespan     | Same as tab  | Independent      |
| Intended use | Parallelism  | Offline support  |

Buksy's answer is basically the last row of the table. Credit: I took this table from Demystifying Web Workers and Service Workers by Nolan Lawson, starting from slide 35.

In particular, here is how you spawn and terminate web workers:

Using Web Workers

whereas service workers have their own lifecycle, which is admittedly their "most complicated part":

The Service Worker Lifecycle

So lifecyle is one fundamental difference between the two (a consequence of their intended use).

There used to be a huge difference in browser support: Service workers were not available at all in Safari for iOS till 11.3 (2018 Mar 29), see Can I use service workers? In contrast, web workers had a much better browser support already in 2012: Can I use web workers?

If you have to support IE11, you can only use web workers: IE11 does not have service workers, and apparently the end of support for IE11 is October 14, 2025.

There are subtle differences in their API support across browsers, see HTML5 Worker Test (also by Nolan Lawson). In a particular browser, one kind of worker might support a certain API call whereas the other does not. Visit that page and test your own browser!

Service workers

Service workers are a proxy between the browser and the network. By intercepting requests made by the document, service workers can redirect requests to a cache, enabling offline access.

/* main.js */

navigator.serviceWorker.register('/service-worker.js');



/* service-worker.js */

// Install 
self.addEventListener('install', function(event) {
    // ...
});

// Activate 
self.addEventListener('activate', function(event) {
    // ...
});

// Listen for network requests from the main document
self.addEventListener('fetch', function(event) {
    // ...
});

Web workers

Web workers are general-purpose scripts that enable us to offload processor-intensive work from the main thread.

/* main.js */

// Create worker
const myWorker = new Worker('worker.js');

// Send message to worker
myWorker.postMessage('Hello!');

// Receive message from worker
myWorker.onmessage = function(e) {
  console.log(e.data);
}

Original Post Here

There is a big difference in what they are intended for:

Web Workers

Web Workers provide a simple means for web content to run scripts in background threads. The worker thread can perform tasks without interfering with the user interface. In addition, they can perform I/O using XMLHttpRequest (although the responseXML and channel attributes are always null). Once created, a worker can send messages to the JavaScript code that created it by posting messages to an event handler specified by that code (and vice versa.)

Source - Using Web Workers

Service Worker

Service workers essentially act as proxy servers that sit between web applications, and the browser and network (when available). They are intended to (amongst other things) enable the creation of effective offline experiences, intercepting network requests and taking appropriate action based on whether the network is available and updated assets reside on the server. They will also allow access to push notifications and background sync APIs.

Source - Service Worker API

So Web Workers are handy to run expensive scripts without causing the user interface to freeze, while Service Workers are useful to modify the response from network requests (for example, when building an offline app).