The Limits of WebGPU and WebAssembly in the Browser (November 2026)
TTSLab exists because voice AI can now run entirely in a browser tab: TTS, STT and a small LLM, no server, powered by WebGPU and WebAssembly. But the same platform limits that make this remarkable also define exactly where it stops working — which models run, which fall back to WASM, which are marked unsupported, and why your downloaded model can disappear. This page is the documented, sourced version of every limit the demos run into. Each claim links to its source; nothing here is invented.
Last updated November 8, 2026.
What changed in the last 12 months
2025–2026 closed most of the availability gap but almost none of the capability gap. Chronological, newest last:
Sep 15, 2025
Safari ships WebGPU by default
Safari 26.0 turned WebGPU on by default on macOS, iOS, iPadOS and visionOS — the last major engine to do so (Safari 26.0 release notes).
Sep 17, 2025
Wasm 3.0 is finalized
The WebAssembly Working Group completed Wasm 3.0, adding memory64, garbage collection and multi-memory to the standard (WebAssembly roadmap).
Aug 2026
Subgroups land in Chromium only
Chrome 151–152 shipped the subgroup-size-control feature, unlocking single-instruction parallel reductions in compute shaders. Safari and Firefox have not shipped it (gpuweb implementation status).
Aug 2026
WebNN origin trial closes
Chrome's WebNN origin trial ended; the API remains flag-gated and is not production-ready (Chrome for Developers, WebNN status).
Aug 2026
Kokoro-82M, both backends, measured
Published measurements put Kokoro-82M on an M1 Max at a 0.105 real-time factor over WebGPU and 2.002 over single-threaded WASM q8 — a 19× spread between the two backends on the same machine (briantung.me).
Oct 2026
Speculative decoding closes the LLM gap
Research demonstrated 3.5–8.6× decode speedups over WebLLM in the browser using speculative decoding (arXiv 2610.39761).
Nov 2026
Coverage sits near 89%
WebGPU is default-on in Chrome/Edge 113+ (every platform including Android 12+, since May 2023 — Chrome for Developers), Safari 26.0+ on all Apple platforms, Firefox 141 on Windows (July 2025 — Firefox 141 release notes), Firefox 145 on macOS 26 Tahoe (Nov 2025) and Firefox 147 on all Apple-Silicon Macs (Jan 2026). That totals about 88.6% of browsers globally (caniuse, November 2026). The uncovered gaps: Firefox on Linux and Android, Safari on Intel Macs, Chrome on Windows ARM64.
The hard ceilings
Defaults from the WebGPU spec are not ideals — they are the numbers your code gets unless the adapter proves it can do better, and some limits are not requestable at all.
| Limit | Default | Reality / ceiling | Where it bites this site | Source |
|---|---|---|---|---|
| GPU buffer size (maxBufferSize) | 256 MiB | Requestable up to 4 GiB on capable desktop GPUs | Model binaries above 256 MiB need multi-buffer loading on stock limits | W3C WebGPU spec |
| Storage buffer binding (maxStorageBufferBindingSize) | 128 MiB | 2 GiB or larger bindings on only about 16% of devices; mobile is the constraint | Large weight tensors must be split before they fit a single binding | Web3D Survey |
| shader-f16 | Off | Supported on roughly 94% of adapters | Half-precision kernels fall back to f32 on the remainder | Web3D Survey |
| Subgroups | Off | Chromium-only (Chrome 151–152, Aug 2026); Safari and Firefox lag | Fast reductions and softmax kernels stay portable-CPU or slower paths elsewhere | gpuweb implementation status |
| timestamp-query | Off | Chromium-skewed availability | GPU timing instrumentation is not portable, so in-browser profiling is approximate | gpuweb implementation status |
| Per-tab committed memory on iOS Safari | Hard kill at roughly 1.5–2 GB (measured on iPhone 15 Pro) | The tab is terminated with no device.lost event and no JS error | GPU and WASM allocations share one per-tab budget; large models can silently die on load | nearform/crashbox |
| wasm32 module memory | 4 GiB practical ceiling | 32-bit pointers cap a single module at 4 GiB | Big quantized LLMs plus activation memory crowd the same 4 GiB | WebAssembly roadmap |
| memory64 (Wasm 3.0) | Spec-final since Sep 17, 2025 | Chrome 133+, Firefox 134+, Safari only in the 27 line — and llama.cpp / wllama do not use it yet | The theoretical fix for the 4 GiB cap is not reachable from today's in-browser LLM engines | WebAssembly roadmap |
| relaxed-simd | Flag-only in Safari | Unflagged in Firefox 145 (Feb 2026); stable in Chromium | SIMD-optimized CPU kernels run slower on Safari's WASM engine | WebAssembly roadmap |
| SharedArrayBuffer / WASM threads | Requires cross-origin isolation | COOP + COEP headers are mandatory in every browser | This site sets COOP same-origin and COEP credentialless to enable threaded WASM | MDN SharedArrayBuffer |
| Origin storage quota | Chrome/Edge: about 60% of disk. Firefox: min(10% of disk, 10 GiB). Safari: up to 60% | Safari additionally evicts after 7 days without interaction unless storage is persisted | A 2 GB model cache can silently vanish on iOS — the reason users re-download models | MDN storage quotas |
| WebNN | Not shipped | Origin trial closed Aug 2026; still flag-gated | No production NPU path in a browser tab yet | Chrome for Developers |
Why the buffer defaults matter: the spec presets every adapter at 256 MiB for maxBufferSize and 128 MiB for maxStorageBufferBindingSize (W3C WebGPU spec). An app can ask for up to 4 GiB on a capable desktop GPU, but telemetry shows storage bindings of 2 GiB or more exist on only about 16% of real devices, with mobile the dominant constraint (Web3D Survey). This is why multi-GiB model weights are sharded rather than loaded as one buffer.
On the CPU side, a wasm32 module still tops out at 4 GiB of linear memory (WebAssembly roadmap). Wasm 3.0 — finalized September 17, 2025 with memory64, GC and multi-memory — is shipped in Chrome 133 and Firefox 134 but only in Safari's 27 line, and the engines people actually run in tabs (llama.cpp, wllama) do not use memory64 yet, so the practical ceiling stands (WebAssembly roadmap). Meanwhile relaxed-simd, which accelerates quantized CPU kernels, was unflagged in Firefox 145 in February 2026 but remains flag-only in Safari (WebAssembly roadmap). Threads via SharedArrayBuffer still require cross-origin isolation — COOP plus COEP — in every browser (MDN SharedArrayBuffer); this site sets those headers site-wide for exactly that reason.
The least forgiving limit is physical memory. On iOS, Safari hard-kills the tab when committed memory runs out — the GPU and WASM allocations share one per-tab budget — with no device.lost event and no JavaScript error, at roughly 1.5–2 GB on an iPhone 15 Pro (nearform/crashbox). A "large" model on a laptop is a crashed tab on a phone.
And even when a model loads, browser storage is not a guarantee. Chrome and Edge grant origins about 60% of free disk, Firefox min(10% of disk, 10 GiB), Safari up to 60% — but Safari evicts non-persisted site data after 7 days without user interaction (MDN storage quotas, WebKit blog). Requesting navigator.storage.persist() (MDN storage.persist()) protects a multi-gigabyte model cache from that sweep.
What this means for the models on this site
The backend gap is a 19× performance gap, not a rounding error. Kokoro-82M on an M1 Max runs at a real-time factor of 0.105 over WebGPU — about 9.5× faster than real time — while the single-threaded WASM q8 fallback on the same machine measures 2.002, i.e. half real time (briantung.me). Every TTSLab demo auto-selects WebGPU when the browser offers it, and falls back to WASM when it does not; that fallback is audibly slower on exactly the devices (Linux, older Safari) WebGPU has not reached (caniuse, November 2026).
Missing kernels block whole models. Chatterbox Multilingual is marked unsupported here because the ONNX spec requires INT64 tensors for its Shape and Unsqueeze operations, and the browser WebGPU backend has no INT64 cast kernel — the model cannot run on the GPU at all. This is an ecosystem gap, not a property of the model; when browsers add the kernel, the model unlocks.
LLMs run, at a measurable discount to native. The WebLLM paper measures Llama-3.1-8B at 41.1 tokens per second on an M3 Max in-browser — roughly 71% of native Metal performance on the same hardware (arXiv 2412.15803). Per-dispatch CPU-side overhead of 24–36 µs on Vulkan and 32–71 µs on Metal at batch size 1 (arXiv 2604.02344, arXiv 2608.08730) is a large part of why small models with fewer, larger kernels fare better in a tab. Speculative decoding research shows 3.5–8.6× faster WebLLM decode is reachable without changing the platform (arXiv 2610.39761).
Memory and storage limits decide mobile behavior. The iOS per-tab kill radius (nearform/crashbox) and Safari's 7-day storage eviction (MDN storage quotas) are why we recommend Moonshine Tiny or Kokoro on phones, and why a model you downloaded last week may need re-downloading today.
WebNN is not a rescue yet. A native NPU API would sidestep most of the ceilings above, but Chrome's WebNN origin trial closed in August 2026 and the API remains flag-gated (Chrome for Developers, WebNN status). Nothing on this site depends on it.
Sources
- caniuse, November 2026 — https://caniuse.com/webgpu
- Chrome for Developers — https://developer.chrome.com/blog/webgpu-release
- Safari 26.0 release notes — https://developer.apple.com/documentation/safari-release-notes/safari-26-release-notes
- Firefox 141 release notes — https://www.mozilla.org/en-US/firefox/141.0/releasenotes/
- W3C WebGPU spec — https://www.w3.org/TR/webgpu/
- Web3D Survey — https://web3dsurvey.com/webgpu
- gpuweb implementation status — https://github.com/gpuweb/gpuweb/wiki/Implementation-Status
- nearform/crashbox — https://github.com/nearform/crashbox
- WebAssembly roadmap — https://webassembly.org/roadmap/
- MDN SharedArrayBuffer — https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer
- arXiv 2604.02344 — https://arxiv.org/abs/2604.02344
- arXiv 2608.08730 — https://arxiv.org/abs/2608.08730
- briantung.me — https://briantung.me/blog/tts-engines-in-the-browser/
- arXiv 2412.15803 — https://arxiv.org/abs/2412.15803
- arXiv 2610.39761 — https://arxiv.org/abs/2610.39761
- MDN storage quotas — https://developer.mozilla.org/en-US/docs/Web/API/Storage_API/Storage_quotas_and_eviction_criteria
- WebKit blog — https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/
- MDN storage.persist() — https://developer.mozilla.org/en-US/docs/Web/API/StorageManager/persist
- Chrome for Developers — https://developer.chrome.com/docs/web-platform/webnn
- WebNN status — https://webmachinelearning.github.io/webnn-status/
Run the demos yourself on the models page to see where your own hardware lands against these ceilings.