WASM Threads: Browser Support, Atomics, COOP/COEP

What is WASM Threads?

WASM threads is a WebAssembly extension from the W3C WebAssembly Working Group that adds shared linear memory and atomic memory instructions. The browser runs each Wasm thread inside a Web Worker and shares one SharedArrayBuffer-backed memory between them so a Wasm module can use real parallelism.

Which browsers does WASM Threads support?

Every major engine ships WASM threads on desktop and mobile, with global usage near 95%, but every browser still requires the page to be cross-origin isolated through COOP and COEP before SharedArrayBuffer is exposed.

How do WASM Threads work?

WASM threads stack three browser primitives - Web Workers, SharedArrayBuffer, and Wasm atomics - to give a Wasm module real parallelism. The Wasm module imports a shared linear memory; the main thread spawns one Web Worker per logical CPU core; every worker instantiates the same module against the same SharedArrayBuffer-backed memory. Atomic instructions (atomic.load, atomic.store, atomic.rmw, atomic.wait, atomic.notify) let one thread sleep on a memory address until another thread wakes it.

Higher-level synchronization primitives like mutexes, channels, and read-write locks build on those wait and notify atomics. Toolchains such as Emscripten for C and C++, and wasm-bindgen-rayon for Rust, hide this plumbing and expose familiar pthread or Rayon iterator APIs instead.

// Paste this into the DevTools console of a cross-origin isolated page
// to confirm WASM threads support.
async function hasWasmThreads() {
  if (typeof SharedArrayBuffer === "undefined") {
    return false;
  }

  try {
    new WebAssembly.Memory({ initial: 1, maximum: 1, shared: true });
    return true;
  } catch (err) {
    return false;
  }
}

hasWasmThreads().then((supported) => {
  if (supported) {
    console.log("WASM threads are available on this page.");
  } else {
    console.log("WASM threads are not available. Check COOP and COEP headers.");
  }
});

How do you enable WASM Threads in your browser?

WASM threads ship on by default in every supported browser, but the page itself has to opt in to cross-origin isolation. Without the right headers, SharedArrayBuffer is undefined and the Wasm module fails to spawn workers.

• Send the COOP header: Set Cross-Origin-Opener-Policy: same-origin on the top-level HTML response so the browser process-isolates the page from cross-origin openers.
• Send the COEP header: Set Cross-Origin-Embedder-Policy: require-corp on the same response so every subresource has to opt in to being embedded.
• Opt in every cross-origin subresource: Serve images, fonts, scripts, and Wasm files with Cross-Origin-Resource-Policy: cross-origin or a CORS response, otherwise the browser blocks them.
• Reload the page: Cross-origin isolation only applies to a freshly loaded document. Hard-reload after editing the headers so the next load picks up the new policy.
• Confirm the gate: Open the DevTools console and check that crossOriginIsolated is true and typeof SharedArrayBuffer is "function". If either fails, the COOP or COEP header is missing or a cross-origin subresource was blocked.
• Run feature detection: Paste the snippet from the previous section into the console to confirm WebAssembly.Memory accepts the shared: true flag before loading the threaded Wasm module.

If crossOriginIsolated stays false, open the Network panel, look for a blocked subresource, and add the missing CORP or CORS header on its origin.

What are the use cases of WASM Threads?

WASM threads pay off whenever a workload is CPU-bound and embarrassingly parallel, since the cost of moving bytes through postMessage already dominated the previous Web Worker pattern.

• Image and video codecs: Squoosh uses WASM threads for client-side image compression and reports 1.5x to 3x speedups depending on the codec. FFmpeg.wasm encodes and transcodes video in the browser using a threaded build of libavcodec.
• 3D engines and games: Unity, Unreal Engine, and Godot ship threaded Wasm builds so the physics, animation, and audio systems can run on separate worker threads while the render loop owns the main thread.
• PDF and CAD viewers: Apryse, PDFTron, and AutoCAD Web use WASM threads to parse, render, and search large documents without freezing the main thread.
• Cryptography and ZK proofs: Browser-side cryptography libraries and zero-knowledge proof generators parallelize hashing and field arithmetic across CPU cores using threaded Wasm builds.
• Scientific computing: Pyodide, R for Wasm, and BLAS-on-Wasm builds use threads to keep linear algebra workloads close to native speed inside the browser sandbox.

What are the known issues with WASM Threads?

WASM threads are stable across every major engine, but the cross-origin isolation requirement and the worker startup cost still trip teams up in production.

• COOP and COEP break embedded content: Cross-Origin-Embedder-Policy: require-corp blocks any iframe, image, or script that does not opt in. Ad networks, third-party analytics, and legacy CDN assets often lack the CORP or CORS header and silently disappear.
• SharedArrayBuffer is gated to secure contexts: The page must be served over HTTPS and be cross-origin isolated. localhost works for development, but plain HTTP staging environments do not, which surprises QA teams the first time.
• Worker startup is expensive: Spawning one Web Worker per CPU core takes 20 to 100 ms each on mid-range mobile, so a fresh page load that immediately spins up a thread pool feels janky. Pool the workers and reuse them.
• Memory growth is shared: When one thread calls memory.grow, every other thread sees the new pages. The toolchain has to handle the case where a pointer becomes stale during reallocation.
• Debugger support is uneven: Chrome DevTools and Firefox DevTools step through threaded Wasm using DWARF, but breakpoints inside a worker thread sometimes fail to bind on Safari Web Inspector.

In my experience, the COOP and COEP rollout is the single most expensive part of shipping WASM threads - the headers force every embedded asset to be audited, and the page silently falls back to single-threaded mode when one CDN forgets to send Cross-Origin-Resource-Policy.

Citations

All WASM threads version numbers and platform notes in this guide come from these primary sources:

• WebAssembly threads proposal (GitHub): github.com/WebAssembly/threads
• WebAssembly 2.0 + Threads spec draft: webassembly.github.io/threads/core
• WebAssembly feature status: webassembly.org/features
• web.dev - Using WebAssembly threads from C, C++ and Rust: web.dev/articles/webassembly-threads
• MDN - WebAssembly.Memory: developer.mozilla.org/.../WebAssembly/JavaScript_interface/Memory
• MDN - SharedArrayBuffer: developer.mozilla.org/.../SharedArrayBuffer
• MDN - Cross-Origin-Embedder-Policy: developer.mozilla.org/.../Cross-Origin-Embedder-Policy
• Mozilla Hacks - Safely reviving shared memory: hacks.mozilla.org/2020/07/safely-reviving-shared-memory
• Chrome Platform Status - WebAssembly Worker Based Threads: chromestatus.com/feature/5724132452859904
• WebKit blog - New WebKit features in Safari 15.2: webkit.org/blog/12445/new-webkit-features-in-safari-15-2
• Wikipedia - WebAssembly: en.wikipedia.org/wiki/WebAssembly
• Bytecode Alliance - Announcing wasi-threads: bytecodealliance.org/articles/wasi-threads