WASM Reference Types: Browser Support, Features

What is WASM Reference Types?

WASM Reference Types is a WebAssembly 2.0 extension that adds two opaque value types, externref and funcref, plus support for multiple tables and new table manipulation instructions. It lets Wasm code hold direct references to host objects and functions without storing them in linear memory.

Which browsers does WASM Reference Types support?

WASM Reference Types works in every modern desktop and mobile browser. Firefox shipped support first, Chrome and Edge followed in version 96, Safari joined with version 15, and roughly 95% of global browser sessions can now run a Reference Types module by default.

What does the WASM Reference Types proposal add?

The proposal extends WebAssembly's type system beyond integers and floats. It adds two opaque reference types, lifts the single-table limit, and gives Wasm code first-class instructions to read and write tables.

• externref value type: An opaque reference to any host value, including JavaScript objects, DOM nodes, and strings. Wasm code can pass externref through globals, locals, parameters, return values, and tables, but cannot inspect or copy the underlying host object.
• funcref as a first-class value type: Function references can now flow through globals, locals, and parameters, not just element segments. This unlocks higher-order functions and lets Wasm modules pass callbacks back to the host without an integer trampoline.
• Multiple tables per module: A Wasm module can declare more than one table, and each table can hold either funcref or externref values. Modular linkers and language runtimes use separate tables to isolate function pointers from host object handles.
• New table instructions: The proposal adds table.get, table.set, table.size, table.grow, table.fill, and table.copy. These instructions let Wasm code read and write tables in line, instead of going through host glue for every lookup.
• Foundation for future proposals: Typed function references, exception handling, and WebAssembly GC all build on Reference Types. Without externref and the new table model, those proposals could not represent host objects or typed references.
• Spec-level inclusion in WebAssembly 2.0: Reference Types is no longer a separate proposal. The W3C WebAssembly Core Specification 2.0 absorbs it into the base type system, so every conformant engine implements it.

What are the use cases of WASM Reference Types?

WASM Reference Types pays off anywhere a Wasm module needs to talk to the host without copying or serializing. Production teams ship it in language runtimes, framework bindings, and toolchains that bridge Wasm and JavaScript.

• Rust and wasm-bindgen DOM bindings: wasm-bindgen emits externref-based bindings for web-sys and js-sys, which removes the legacy integer side table and shrinks generated glue. Yew, Leptos, Dioxus, and the Rust DOM frameworks all rely on this path.
• Pyodide and Python in the browser: Pyodide stores PyObject handles as externref so Python code can hold direct references to JavaScript values without an integer index map. The same pattern powers JupyterLite, Marimo, and PyScript.
• Blazor WebAssembly and .NET interop: Blazor uses externref to pass JavaScript objects across the .NET to JS boundary without marshalling. The .NET runtime in browser apps holds DOM elements as externref handles for direct event wiring.
• Modular linking and dynamic loading: Multi-table support lets Emscripten and Wasmer load multiple Wasm modules side by side, each with its own function table. Plugin systems and hot-reload workflows depend on this isolation.
• Higher-order functions and callbacks: Game engines and UI frameworks use funcref values to pass callbacks across module boundaries. Bevy, Godot, and Unity WebGL exports all benefit from first-class funcref handling.
• Foundation for WebAssembly GC adopters: Languages that compile to WebAssembly GC, including Kotlin, Dart, OCaml, and Java via TeaVM, depend on Reference Types as the underlying value model. Without it, the GC proposal cannot represent host references.

How do you check if a browser supports WASM Reference Types?

Run WebAssembly.validate() against a tiny module that declares a table of externref. The call returns true on every browser that supports WASM Reference Types and false everywhere else, with no need to instantiate or execute the module.

Paste this snippet into the DevTools console of any browser to confirm support, and use the same probe inside your loader to pick the right WebAssembly build:

// Run in the DevTools console of any modern browser to feature-detect WASM Reference Types.
// The byte array below is a minimal Wasm module that declares a single table of externref.
// Browsers without Reference Types support reject the module at validation time.
const refTypesProbe = new Uint8Array([
  0x00, 0x61, 0x73, 0x6d, 0x01, 0x00, 0x00, 0x00,
  0x04, 0x04, 0x01, 0x6f, 0x00, 0x00
]);

const supportsRefTypes = WebAssembly.validate(refTypesProbe);
console.log("WASM Reference Types:", supportsRefTypes ? "supported" : "not supported");

// Branch your loader so older browsers fall back to a glue-code build.
const wasmUrl = supportsRefTypes ? "/build/app.reftypes.wasm" : "/build/app.glue.wasm";

For projects that need many feature checks at once (Reference Types, SIMD, threads, GC), use the wasm-feature-detect package on npm. It wraps the same WebAssembly.validate technique behind a one-line referenceTypes() promise that resolves to true or false.

What are the known issues with WASM Reference Types?

WASM Reference Types covers about 95% of global browser sessions, but a few real edge cases still bite production teams. The biggest hits are older Safari and iOS, the toolchain split between bindgen-glue and externref builds, and the limited debugger support for opaque values.

• Older Safari and iOS lag: Safari 11 to 14 on macOS and iOS 11 to 14 reject any module that uses externref, funcref as a value type, or multiple tables. A module built only with reference-types fails to instantiate on these versions, so loaders must ship a glue-code fallback.
• Toolchain version floor: Emscripten 3.1.4 and earlier, wasm-bindgen 0.2.78 and earlier, and Rust 1.56 and earlier do not emit reference-types output by default. Older builds keep using integer side tables and pay the glue-code cost on every host call.
• Debugger support is opaque: Chrome DevTools and Firefox DevTools show externref values as a generic Ref or anyref label with no way to inspect the underlying JavaScript object from the Wasm debugger. Safari Web Inspector hides the value entirely.
• Internet Explorer is a hard miss: IE 5.5 through 11 never added WebAssembly, and there is no polyfill for externref or funcref. Sites that still target IE 11 need a JavaScript-only path with no Wasm path at all.
• Memory leaks via held references: Holding an externref inside a Wasm global or table prevents the host garbage collector from reclaiming the underlying object. Long-lived modules need to clear externref slots when handles are no longer needed.
• Build pipeline complexity: Production teams ship two binaries, app.reftypes.wasm and app.glue.wasm, plus a feature-detect loader. CDN cache keys, integrity hashes, and source map paths all double for the fallback path.

In my experience, the most surprising failure happens on iOS 14 and earlier. A wasm-bindgen Rust app that runs on every desktop browser and Safari 15+ fails to instantiate on iOS 14 with a generic CompileError, because JavaScriptCore on iOS 14 rejects externref tables before any code runs. Always wire a glue-code fallback into the loader and validate it against a real iOS 14 device before release.

Citations

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

• MDN Web Docs - externref reference: developer.mozilla.org/en-US/docs/WebAssembly/Reference/Types/externref
• MDN Web Docs - funcref reference: developer.mozilla.org/en-US/docs/WebAssembly/Reference/Types/funcref
• MDN Web Docs - WebAssembly: developer.mozilla.org/en-US/docs/WebAssembly
• W3C - WebAssembly Core Specification 2.0: w3.org/TR/wasm-core-2
• WebAssembly GitHub - Reference Types proposal: github.com/WebAssembly/reference-types
• WebAssembly.org - Feature Status: webassembly.org/features
• Chrome Platform Status - WebAssembly Reference Types: chromestatus.com/feature/5166497248837632
• WebKit blog - New WebKit Features in Safari 15: webkit.org/blog/12277/new-webkit-features-in-safari-15
• Bytecode Alliance - Reference Types in Wasmtime: bytecodealliance.org/articles/reference-types-in-wasmtime
• Wikipedia - WebAssembly: en.wikipedia.org/wiki/WebAssembly
• Microsoft Learn - Microsoft Edge release notes: learn.microsoft.com/en-us/deployedge/microsoft-edge-relnote-stable-channel