Web Workers

Definition

Web Workers is a browser API that lets JavaScript run scripts on a background thread separate from the page's main thread, allowing computationally expensive work to run without blocking user interface rendering or input handling.

Overview

JavaScript in the browser traditionally runs on a single thread shared with layout, rendering, and event handling, which means a long-running computation — parsing a large file, running an image filter, computing a complex data transformation — blocks the page from responding to clicks, scrolling, or repainting until it finishes. Web Workers exist to solve exactly this problem by giving developers a way to run a separate JavaScript execution context on its own OS-level thread, communicating with the main thread through message passing rather than shared memory, so heavy computation no longer freezes the UI. A worker is created with `new Worker('script.js')`, which loads and runs the given script in its own global context (distinct from `window`, with its own `self`), and communication happens via `postMessage()` and the `onmessage` event handler on both sides. Because workers don't share memory with the main thread by default, data passed between them is either copied (structured clone algorithm) or, for performance-sensitive cases, transferred via `Transferable` objects like `ArrayBuffer`, which hands ownership of the underlying memory to the receiving context without copying it. Workers have no access to the DOM, `window`, or the parent page's variables — they can only use APIs available in their worker global scope, such as `fetch`, timers, and (for supporting APIs) IndexedDB. There are several variants beyond the basic dedicated worker: Shared Workers can be connected to from multiple browsing contexts (tabs or iframes) of the same origin simultaneously, letting them coordinate state across tabs; Service Workers, though technically a related but distinct API, also run off the main thread and are used primarily to intercept network requests for caching and offline support, forming the technical backbone of many Progressive Web Apps. Web Workers are commonly paired with WebAssembly for CPU-intensive tasks like video encoding, physics simulation, or cryptography, since combining the two gets near-native computation speed without touching the responsiveness of the page the user is interacting with.

Specification

• Runs JavaScript on a separate OS-level thread from the main UI thread
• Communication via postMessage()/onmessage message passing, not shared memory
• No direct access to the DOM, window, or main thread variables
• Transferable objects (e.g. ArrayBuffer) allow zero-copy data handoff for performance
• Dedicated Workers (one owning context) vs. Shared Workers (multiple contexts, same origin)
• Related but distinct from Service Workers, which intercept network requests for PWAs
• Commonly paired with WebAssembly for near-native background computation
• Prevents long-running computation from blocking UI rendering and input handling

Use Cases

Alternatives

History

Web Workers give web pages a way to run JavaScript on background threads, so long or expensive computation doesn't block the main thread and freeze the user interface; workers communicate with the page by passing messages rather than sharing memory directly. The WHATWG released the initial draft specification on March 27, 2009, and browser support followed quickly — Firefox 3.5 and Safari 4 in 2009, Chrome 4 in early 2010. The W3C advanced the specification to Candidate Recommendation on May 1, 2012, and it has since evolved continuously within the WHATWG HTML Living Standard. By making it practical to use multi-core CPUs from the web platform, Web Workers became foundational to responsive, compute-heavy web applications.

Frequently Asked Questions

Related in Web