WebAssembly
Last reviewed
May 4, 2026
Sources
20 citations
Review status
Source-backed
Revision
v1 ยท 3,944 words
Improve this article
Add missing citations, update stale details, or suggest a clearer explanation.
Suggest edit
CtrlK
Last reviewed
May 4, 2026
Sources
20 citations
Review status
Source-backed
Revision
v1 ยท 3,944 words
Add missing citations, update stale details, or suggest a clearer explanation.
WebAssembly (often abbreviated Wasm) is a binary instruction format for a stack-based virtual machine, designed as a portable compilation target for high-level programming languages and intended to enable deployment on the web for client and server applications. It executes at near-native speed by taking advantage of common hardware capabilities while running inside a sandboxed environment, and it is supported as an open web standard by all major browsers alongside HTML, CSS, and JavaScript.
Wasm originated as a cross-vendor effort coordinated through the World Wide Web Consortium (W3C) in 2015 and shipped its minimum viable product (MVP) in March 2017 in the four major browser engines. The format was created so that languages such as C, C++, and Rust could run on the web with predictable performance, and so that the same compiled artifacts could later run on servers, edge nodes, embedded devices, and inside other host environments. The W3C published WebAssembly 1.0 as an official Recommendation on December 5, 2019, making it the fourth language with native browser support.
For artificial intelligence and machine learning, Wasm has become a critical piece of in-browser and edge inference infrastructure. Projects such as Hugging Face's Transformers.js, the ONNX Runtime Web, the TensorFlow.js Wasm backend, and the MLC team's WebLLM all rely on WebAssembly, often combined with WebGPU, to run neural networks and large language models entirely on the client. On the server side, edge platforms operated by Cloudflare, Fastly, Vercel, Shopify, and Fermyon use WebAssembly runtimes to host user-supplied AI inference and agent code in fast-starting, isolated sandboxes.
| Field | Value |
|---|---|
| Designed by | W3C WebAssembly Working Group / Community Group |
| Initial release | March 2017 (MVP shipped in major browsers) |
| W3C Recommendation (1.0) | December 5, 2019 |
| Latest specification | WebAssembly 2.0 (Candidate Recommendation Draft, 2024-2025), with Wasm 3.0 in development |
| File extensions | .wasm (binary), .wat (text) |
| Format | Binary instruction format for a stack-based virtual machine |
| Influences | asm.js, Google Native Client (NaCl/PNaCl) |
| Standard | W3C Recommendation; open web standard |
| License | Open standard (no royalties) |
| Major implementations | V8, SpiderMonkey, JavaScriptCore, Wasmtime, Wasmer, WAMR, WasmEdge, Wazero, wasm3 |
| Website | webassembly.org |
The direct predecessors of WebAssembly were two earlier attempts to give the browser a high-performance code path beyond ordinary JavaScript. Google's Native Client (NaCl) and its portable variant PNaCl, first announced in 2011 and shipped in Chrome, allowed C and C++ code to execute inside a browser sandbox at close to native speed, but the technology was Chrome-only and never gained cross-vendor adoption. In 2013, Mozilla engineers introduced asm.js, a strict subset of JavaScript that could be compiled ahead of time by the engine and used as a target for compiling C and C++ programs through Emscripten. Asm.js demonstrated that high-performance native code could run in any browser with no new download format, but it inherited the parsing cost of JavaScript and was bound by the language's text representation.
In April 2015 the WebAssembly Community Group was created at the W3C, and the project's design repository was opened with initial commits by Mozilla engineer Luke Wagner. By the middle of June 2015, Google, Apple, Microsoft, and Mozilla had publicly announced cross-vendor agreement on the new format. Brendan Eich, the creator of JavaScript, summarized the announcement in a widely shared post titled "From ASM.JS to WebAssembly," framing Wasm as the natural successor to asm.js with a compact binary encoding and an open standardization path. Throughout 2016 the four engine teams iterated on a Browser Preview that exercised compatibility across V8, SpiderMonkey, JavaScriptCore, and Chakra.
On February 28, 2017, the four browser vendors declared cross-engine consensus that the MVP was complete. Firefox 52 shipped support on March 7, 2017, followed by Chrome 57 on March 9, 2017. Safari 11 (released September 19, 2017) and Edge 16 (October 31, 2017) added support later that year, completing browser-wide availability. The MVP defined the core instruction set, the linear memory model, the binary and text formats, and the JavaScript embedding API.
W3C standardization continued in parallel. On December 5, 2019, the WebAssembly Core Specification, the JavaScript Interface, and the Web API specifications were jointly published as W3C Recommendations, formally making WebAssembly 1.0 an official web standard alongside HTML, CSS, and JavaScript.
In November 2019, Mozilla, Fastly, Intel, and Red Hat announced the formation of the Bytecode Alliance, a vendor-neutral organization aimed at building secure runtimes and tooling for WebAssembly outside the browser. Founding contributions included Wasmtime, the WebAssembly Micro Runtime (WAMR), and the Cranelift code generator. The alliance later expanded to include Microsoft, Amazon, Arm, Google, Siemens, and others, and incorporated as a 501(c)(6) industry consortium.
After 1.0, the W3C WebAssembly Working Group accepted a steady stream of proposals through a multi-phase process. Features that have shipped widely include 128-bit fixed-width SIMD (v128), threads with shared memory and atomics, exception handling, multi-value returns, bulk memory operations, reference types and tail calls, and a typed garbage collection (GC) extension that reached cross-engine support in 2023. The WebAssembly 2.0 specification, which incorporates these post-1.0 features, was published as a Candidate Recommendation by the W3C in 2024 and a corresponding announcement was made on the WebAssembly project blog in 2025. Work on a 3.0 line, which adds 64-bit memories, the typed function references model, and further GC and exception handling refinements, has been progressing through 2025 and 2026.
WebAssembly defines a stack-based virtual machine that operates over a small number of value types and a flat, byte-addressable linear memory. Programs are organized as modules, each of which declares its imports, exports, functions, tables, memories, globals, and data and element segments. Modules are validated by the host before execution to guarantee type and memory safety, and each module instance runs in a sandbox separated from the host process and from other instances.
The core value types are i32 and i64 for 32-bit and 64-bit integers, f32 and f64 for IEEE 754 single- and double-precision floats, the v128 type added by the SIMD proposal for 128-bit packed vectors, and reference types such as funcref and externref. Instructions consume operands from a virtual stack and push results back, mirroring the structure of typed bytecode formats. Control flow uses structured constructs (block, loop, if, br, br_if, br_table, return, call, call_indirect) rather than arbitrary jumps, which makes single-pass validation and streaming compilation straightforward.
Each module may declare one or more linear memories, which are contiguous, resizable arrays of bytes addressed by 32-bit indices in the original specification. The Memory64 proposal extends addressing to 64 bits for hosts that need it. Tables hold opaque references such as function pointers; the call_indirect instruction performs type-checked dispatch through a table entry, providing a safe substitute for raw function pointers in the source language.
The binary format (.wasm) is a compact, length-prefixed encoding designed for fast streaming compilation, with sections for types, imports, functions, tables, memories, globals, exports, the start function, elements, code, data, and an optional name section that aids debugging. The text format (.wat) uses S-expressions and is intended for human readers and tooling rather than as a deployment format. Tools such as wabt, wat2wasm, and binaryen convert between the two.
Wasm modules are validated in a single pass before they execute. The validation rules guarantee that the program is well-typed at every stack position, that memory and table accesses are bounds-checked, and that control flow is structured. Engines compile the validated module either ahead of time, just in time, or with a tiered combination of the two. Because the bytecode is already low-level and typed, engines avoid much of the speculative optimization machinery that JavaScript JITs require, which gives Wasm consistent performance without a long warmup curve.
WebAssembly itself does not specify any I/O, DOM access, networking, or filesystem. Instead, host environments expose capabilities through imports. In a web browser, the JavaScript Interface and Web API specifications define how Wasm modules interact with the page; on a server, the host might supply WebAssembly System Interface (WASI) APIs or a custom set. This separation lets the same .wasm artifact run in different hosts with the same execution semantics.
The headline goal of WebAssembly is to deliver predictable, near-native performance in a portable, sandboxed format. In practice the runtime cost of the sandbox (bounds checks on memory accesses, indirect call validation, stack overflow checks, and the abstraction layer between Wasm types and host machine types) places a ceiling on how close Wasm can get to hand-tuned native code. Benchmarks published by browser engine teams and academic studies typically place Wasm within roughly a small constant factor of native C, with the gap depending heavily on the workload, the toolchain, and whether SIMD and threads are used.
Compared with JavaScript, Wasm has two practical performance advantages. First, the binary format is fast to parse and validate, and engines can begin compiling the moment bytes arrive over the network, so startup is fast. Second, Wasm has no dynamic typing, no hidden classes, and no inline cache machinery, so once compiled, performance is steady and does not depend on speculative warmup. JavaScript JITs can match or exceed Wasm on numeric microbenchmarks once they have warmed up, but Wasm wins on consistency and on workloads that resist speculative optimization, such as compression, cryptography, image and video processing, physics, and machine learning kernels.
A broad ecosystem of languages and toolchains can produce .wasm modules. The table below summarizes the most established options.
| Language | Toolchain | Notes |
|---|---|---|
| C / C++ | Emscripten, clang with the wasm32 target | The original target audience for Wasm; mature support including SDL ports, OpenGL via WebGL, and POSIX shims. |
| Rust | rustc with wasm32-unknown-unknown, wasm32-wasi, wasm-bindgen | First-class support; popular for browser libraries and edge functions. |
| Go | Mainline gc compiler (GOOS=js, wasm and GOOS=wasip1), TinyGo | TinyGo produces much smaller binaries and is preferred for size-sensitive workloads. |
| AssemblyScript | AssemblyScript compiler (asc) | A TypeScript-like language designed specifically for Wasm. |
| C# / .NET | Blazor WebAssembly, .NET Wasm SDK | Runs the .NET runtime in the browser; used by Microsoft Blazor. |
| Swift | SwiftWasm community toolchain | Experimental but functional. |
| Zig | Zig compiler with wasm32-freestanding or wasm32-wasi | Built-in cross-compilation to Wasm. |
| Python | Pyodide (CPython compiled with Emscripten), Wasmer Py | Used in JupyterLite and Cloudflare Python Workers. |
| Ruby | ruby.wasm | Official Ruby builds compiled to Wasm. |
| Java / JVM | CheerpJ, TeaVM, JWebAssembly | Run Java applets and applications in the browser without a JVM plugin. |
| Kotlin | Kotlin/Wasm | Official Kotlin Wasm backend with GC support. |
| TypeScript | AssemblyScript or via JavaScript transpilation | Direct TS-to-Wasm via AssemblyScript subset; full TS via JS bridge. |
The browser engines V8 (Chrome, Edge, Node.js, Deno, Bun), SpiderMonkey (Firefox), and JavaScriptCore (Safari) all ship Wasm engines, but a parallel ecosystem of standalone runtimes has grown up around server-side, edge, and embedded use cases.
| Runtime | Maintainer | Implementation language | Typical use |
|---|---|---|---|
| Wasmtime | Bytecode Alliance | Rust | General-purpose server and CLI host; reference implementation for WASI. |
| Wasmer | Wasmer, Inc. | Rust | Commercial-friendly runtime with multiple compiler backends (Cranelift, LLVM, Singlepass). |
| WAMR (WebAssembly Micro Runtime) | Bytecode Alliance | C | Embedded and IoT devices; small footprint, interpreter and AOT modes. |
| WasmEdge | CNCF (Cloud Native Computing Foundation) | C++ | Edge and serverless workloads, AI inference extensions. |
| Wazero | Tetrate | Go | Pure Go runtime with no CGO; embeds easily in Go applications. |
| wasm3 | Community | C | Fast interpreter aimed at constrained embedded targets. |
| Lucet | Originally Fastly, now archived in favor of Wasmtime | Rust | Pioneered ahead-of-time Wasm compilation for edge computing. |
Several major commercial platforms run user code on top of WebAssembly:
| Platform | Underlying engine | Notes |
|---|---|---|
| Cloudflare Workers | V8 isolates with Wasm support since 2018 | JavaScript and Wasm guests share a process via V8 isolates; Python Workers use Pyodide compiled to Wasm. |
| Fastly Compute | Wasmtime (replaced the original Lucet runtime) | Each request runs in a fresh Wasm instance; cold start measured in tens of microseconds. |
| Vercel Edge Functions | V8 isolates | JavaScript, TypeScript, and Wasm modules executed at the edge. |
| Shopify Functions | Wasmtime | Customizable storefront and checkout logic supplied by merchants. |
| Fermyon Spin | Wasmtime | Open-source serverless framework focused on Wasm components. |
| Cosmonic / wasmCloud | Wasmtime via wasmCloud | Distributed application platform built on Wasm components. |
The WebAssembly System Interface is a family of standardized APIs that lets Wasm modules interact with operating system facilities such as the filesystem, clocks, random number generation, environment variables, and (in newer revisions) sockets and HTTP. WASI was originally announced by Mozilla in 2019 and is now developed by a W3C subgroup with participation from the Bytecode Alliance and other vendors.
WASI Preview 1 (sometimes called wasi_snapshot_preview1) defined a POSIX-like, capability-based API surface that quickly became the de facto standard for non-browser Wasm. Programs targeting WASI Preview 1 obtain capabilities (for example, a directory handle) from the host at instantiation rather than calling open() against a global filesystem; this restricts the blast radius of a misbehaving module.
WASI Preview 2, finalized in early 2024, is the first version built on top of the Component Model. Instead of a flat list of imports, Preview 2 organizes APIs into versioned interfaces described in WIT (the WebAssembly Interface Type language) and groups them into worlds. Specific interfaces include wasi:filesystem, wasi:cli, wasi:io, wasi:clocks, wasi:sockets, and wasi:http. The shift to the Component Model lets WASI evolve API by API rather than as a single monolithic import set.
The Component Model is a layer above the core WebAssembly specification that allows modules written in different source languages to interoperate through well-typed interfaces rather than the raw integer-and-pointer ABI of core Wasm. It introduces:
The Component Model is the foundation of WASI Preview 2 and is the basis for emerging tooling such as Fermyon Spin and wasmCloud. Bindings generators exist for Rust (wit-bindgen), TinyGo, JavaScript (jco), Python, C, and several other languages, and component runtimes are available in Wasmtime, WasmEdge, and others.
WebAssembly has become a foundational technology for client-side and edge artificial intelligence. Modern browsers and JavaScript runtimes expose Wasm as the high-performance compute path for machine learning libraries, and the Component Model and WASI extensions are increasingly used to package inference engines for server and edge deployment.
| Project | Wasm role | Notes |
|---|---|---|
| Transformers.js (Hugging Face) | Loads quantized ONNX models and runs them through ONNX Runtime Web's Wasm and WebGPU backends. | Provides a JavaScript API similar to the Python transformers library; supports dozens of model architectures. |
| ONNX Runtime Web | Compiles ONNX Runtime to Wasm with optional SIMD and threads; offers a WebGPU backend for accelerated tensor ops. | Default execution provider for Transformers.js and many Hugging Face demos. |
| TensorFlow.js Wasm backend | Replaces the JavaScript CPU backend with a Wasm build of TensorFlow Lite kernels. | Often paired with the WebGL or WebGPU backend depending on hardware. |
| WebLLM | Compiles model graphs through MLC-LLM and TVM into WebGPU shaders, with a Wasm runtime for graph orchestration and quantization kernels. | In-browser chat with Llama, Mistral, Gemma, Phi, and other large language model families; falls back to Wasm where WebGPU is unavailable. |
| MLC LLM | Same compiler stack as WebLLM, also targets native, iOS, and Android. | Demonstrates end-to-end LLM compilation across browser and device. |
| Web Stable Diffusion | Uses MLC-LLM tooling to compile the Stable Diffusion pipeline to WebGPU plus Wasm. | Runs the full image generation pipeline in the browser. |
| llama.cpp | Provides experimental Wasm builds and WASI ports of its inference loop. | Used in browser demos and in WASI hosts that want a single-binary LLM runtime. |
| Pyodide | Ships CPython, NumPy, SciPy, scikit-learn, and PyTorch (CPU) compiled to Wasm. | Used by JupyterLite and by Cloudflare Python Workers; lets data scientists run notebooks without a server. |
These tools share a similar architecture: model weights are downloaded and quantized, tensor kernels run on the GPU through WebGPU when available, and a Wasm module handles control flow, tokenization, sampling, and any kernels not yet ported to GPU shaders. Wasm SIMD and threads are particularly important for CPU inference, and Wasm 2.0 features such as relaxed SIMD give engines more freedom to map operations to native vector instructions.
On the server, WebAssembly runtimes such as Wasmtime, WasmEdge, and Wasmer have become a common substrate for AI workloads that need fast cold starts, strong isolation, and language portability. Cloudflare Workers AI exposes Meta Llama, Mistral, and other open-weight models behind a Workers API; user code that orchestrates these models runs as JavaScript or Wasm inside V8 isolates. Vercel's AI runtime and Edge Functions similarly use V8 isolates that can host Wasm. Fermyon Spin offers a templated way to build Wasm-based microservices that call into local or remote inference. WasmEdge ships extensions for Llama-family models via llama.cpp and for ONNX Runtime, allowing inference inside a WASI sandbox without depending on a Python runtime.
The combination of Wasm portability, capability-based security, and microsecond-scale instantiation makes the format particularly well suited to running untrusted AI agent code, plug-in marketplaces for hosted assistants, and per-request inference glue at the edge.
WebAssembly is supported in 100% of major browsers in current use, including Chrome, Firefox, Safari, and Edge, and is available in Node.js, Deno, and Bun out of the box. The format is used in production by a long list of consumer and enterprise applications:
| Application | Use of Wasm |
|---|---|
| Figma | The core editor's vector engine is C++ compiled to Wasm. |
| Adobe Photoshop on the web | Large parts of the C++ Photoshop codebase are compiled to Wasm via Emscripten. |
| AutoCAD Web | The AutoCAD engine is shipped to the browser as Wasm. |
| Google Earth on the web | Earth's C++ rendering engine runs in the browser via Wasm. |
| 1Password | The cryptographic core of the 1Password browser extension and web client is Wasm. |
| eBay barcode scanner | Native barcode scanning library compiled to Wasm. |
| Amazon Prime Video | Performance-critical playback components delivered as Wasm. |
| Google Meet | Background blur and noise suppression use Wasm-based ML kernels. |
| Zoom Web | Wasm modules for video processing and audio. |
| Disney+ | Wasm components in their web player. |
Server-side adoption follows a similar pattern. Cloudflare has reported that its Workers platform processes trillions of requests per month, with a growing share running Wasm guests; Fastly Compute reports tens of microseconds of cold-start time for Wasm modules, an order of magnitude better than container-based serverless platforms; Shopify Functions allows merchants to upload Wasm modules to customize commerce logic; and the WebAssembly System Interface has become a portable target for plug-in systems in databases, observability tools, and developer platforms.
WebAssembly's design choices come with trade-offs. Common criticisms and limitations include: