Web Workers
A browser API for running JavaScript on a background thread separate from the main UI thread
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.
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.
Sources
- MDN Web Docs — Web Workers API · as of 2026-07-17
- WHATWG HTML Living Standard — Web workers · as of 2026-07-17
Frequently Asked Questions
From the Blog
What Is Employee Experience and Why Does It Matter?
Employee experience is how workers perceive every touchpoint with their employer, from onboarding to daily tools. This guide explains what shapes workplace experiences, why it drives retention and productivity, and how technology is reshaping it.
Read More Data ScienceHow to make a PyTorch training run reproducible
Reproducibility has three layers: seeding every random source including DataLoader workers, forcing deterministic kernels, and pinning the environment and data version. Fixing only the seed is why two runs still diverge. Learn what to pin, what it costs, and when variance is the result worth reporting.
Read More ProgrammingSharing state between Python processes with multiprocessing
Every way of sharing data between Python processes trades copy cost against coordination cost. Learn what start methods let workers inherit, why pickling usually dominates, when shared memory earns its locking burden, and how restructuring often removes the need to share anything at all.
Read More