WebAssembly 3.0 Deep-Dive: Spec, Telemetry, and Engine Reality

WebAssembly 3.0 Deep-Dive: Spec, Telemetry, and Engine Reality

Executive Summary

WebAssembly 3.0 is a technically honest and well-engineered standard whose narrative does not survive scrutiny; its presence in production is roughly two orders of magnitude lower than commonly assumed.

Key findings:

• Adoption is 90x lower than the popular "5.5%" claim. Chrome UseCounter data shows real Wasm instantiation at 0.0613% of page loads, not 5.5%.
• The W3C has no document named wasm-core-3. The 3.0 text physically resides in a Candidate Standard whose short name is still wasm-core-2.
• Two official documents give three contradictory answers about which features belong to 3.0. One Phase-1 proposal (Profiles) was written into the spec body without a corresponding proposal directory.
• Memory64 usage is 0.00000146% of loads and is *lower* today than its 2024 pre-flag-off peak. V8's internal page count is still 32-bit; on 32-bit hosts, memory64 yields exactly zero extra bytes versus memory32, at full performance cost.
• New exception handling (exnref) is used ~28,900x less than the legacy form it replaced. Kotlin/Wasm's official documentation still requires "legacy exception handling."

---

Key Points

1. Version Timeline: What "Wasm 3.0" Actually Is

• 2025-09-17: Wasm 3.0 declared complete as the new live standard.
• 2026-07-28: Render date of the current core spec text.
• Wasm 3.0 will never become a W3C Recommendation. Spec editor Andreas Rossberg explicitly stated the WG switched to an evergreen model after 2.0. The Candidate Recommendation will be updated in place without ever transitioning to final Recommendation status.
• No errata document exists for 3.0; corrections roll directly into spec/main.
• "Engine support precedes standard sign-off by years" is the norm, not the exception. WasmGC shipped in Chrome 119 (2023); the standard was frozen on 2025-09-17.

2. The Spec Body Contains Three Contradictions

The proposal tracking table lists 11 features as Spec Version = 3.0; the core spec's Release 3.0 Change History lists 10. The symmetric difference reveals three discrepancies:

1. Branch Hinting — listed in proposals as core/3.0, absent from core Change History. 2. JS String Builtins — listed as core, js-api/3.0, but only js-api was actually modified. 3. Profiles — not in the proposal table at all (still Phase 1), yet appears in the core Change History and is the only entry without a footnote (no github.com/WebAssembly/spec/tree/main/proposals/<name>/ link exists for it).

Profiles is a Phase-1 proposal whose output bypassed the phased process entirely and was written directly into the 3.0 spec body. This is visible from the document's own footnote numbering: 7, 8, 9, 10, 11, 12, 13, 14, (none), 15.

3. Telemetry: 3.0 Left No Mark on Real-World Traffic

Chrome WebAssemblyInstantiation over time:

| Date | Value | |---|---:| | 2023-09-01 | 0.0295% | | 2024-09-01 | 0.0473% | | 2025-03-20 (Wasm 2.0 announcement) | 0.0459% | | 2025-09-17 (Wasm 3.0 announcement) | 0.0501% | | 2026-08-04 | 0.0613% |

No inflection point appears around the 3.0 announcement. At this slope, Wasm would need ~15 years to reach 1% of page loads.

4. Memory64: A Six-Layer Gap

| Layer | Cap | Source | |---|---:|---| | 1. Core spec (validation) | 16 EiB | memory64 validation rules | | 2. SM/JSC declared | ~8 PiB | WasmConstants.h / WasmLimits.h | | 3. V8 architectural ceiling | 128 TB | wasm-limits.h L103–108 | | 4. JS-API spec (grow) | 16 GiB | js-api #limits | | 5. V8 actual (64-bit host) | 16 GiB | kSpecMaxMemory64Pages | | 5′. V8 actual (32-bit host) | 2 GiB | identical to memory32 | | 6. Practically reachable | Less than 16 GiB | eqrion, spec issue #1892 |

The V8 source explicitly states: > "Even for 64-bit memory, the number of pages is still a 32-bit number for now, which allows for up to 128 TB memories (2**31 * 64k)."

The spec chair Ben Visness is on record (spec issue #1892, 2025-10-08) opposing further memory limit increases without first adding APIs to release memory back to the OS: > "We still don't even have a way to release memory back to the operating system when you're done with it."

5. Exception Handling: Six Years Around in Circles

Three generations:

• Gen1 (2017): first-class exnref + structured try/catch
• Gen2 (2020-09-15): try/catch/delegate/rethrow; exnref removed
• Gen3 (2023-10, Wasm 3.0): try_table + throw_ref + exnref as heap type — exnref reintroduced

Six years back to exnref. Issue #281's Migration Plan states that "deprecation may not be feasible" for the old instructions.

Real-world usage (30-day median):

• Legacy EH (V8WasmExceptionHandling): 0.00607324%
• New exnref (V8WasmExnRef): 0.00000021%
• Ratio: ~28,900:1 — legacy still handles ~99.9965% of Wasm exceptions in the wild

6. Multi-Memory: 1000x Engine Divergence

| Engine | Multi-memory cap | |---|---:| | V8 | 100,000 | | SpiderMonkey | 100 | | JSC | 100 |

Code designed against V8's headroom will crash on Firefox/Safari, and the conformance test suite will not catch it.

7. Statistics That Must Not Be Quoted

| Claim | Reality | |---|---| | "5.5% of Chrome pages use Wasm" | False. Real: 0.0613% (90x lower). | | "4.5% last year" | Same source, same error. | | "41% of sites use Wasm" | Implausible; likely a misread of "41.7% of Wasm modules are .NET". | | "Memory64 gives 16 EiB" | Confuses validation cap with practical cap. | | "Kotlin/Wasm is 50–70% smaller" | No official source; not found on kotlinlang.org. | | "Fermyon 75M req/s" | No first-party benchmark found. | | "Wasm 3.0 released 2026-06-13" | Date incorrect. | | "Safari 145" | No such version exists. |

8. Honest Caveats

• Chrome telemetry only covers Chrome, not Firefox/Safari, and only users with UMA reporting enabled.
• Server-side Wasm is not measured at all — Wasmtime, Fermyon, Fastly, and Cloudflare Workers are invisible to UseCounter. If Wasm's main battleground has shifted server-side, this report systematically understates its real importance.
• UseCounter counts "at least once per page load," not call frequency. A page calling Memory64 ten thousand times counts the same as one call.
• UseCounter has no origin/URL dimension. All "which site does this?" claims are strong inference, not evidence.