For decades, JavaScript was the only language able to run inside the browser. Everything else —Python, C++, Rust— was left out, doomed to run on a server. WebAssembly (short for wasm) broke that monopoly: today it is a binary format that browsers execute at nearly native speed, without going through JavaScript. It is the engine that lets Figma draw in your tab, Google Maps fit millions of map pieces, or an image editor run heavy filters locally.
To understand it, it helps to recall what happened before. JavaScript is an interpreted, dynamically typed language: when the browser encounters it, it compiles it on the fly with a JIT (just-in-time compiler), generating machine code while the program is already running. It is fast, but costly: the engine must infer types in real time, recompile when it guesses wrong, and allocate memory dynamically. That overhead shows up in compute-intensive tasks, like processing a video or scanning millions of data points.
A binary built for the machine, not for humans
WebAssembly attacks the problem at the root. It is not a source language you write: it is a binary you compile beforehand from C, C++, Rust, Go, Zig, or dozens of other languages. That binary is a set of instructions for a virtual stack machine: each operation takes its operands from a stack, processes them, and leaves the result on top. Because it is built for direct execution, the browser can decode and validate it in microseconds and compile it to native code with a simple AOT (ahead-of-time) compiler, with no type guessing and no recompilation.
The result is low-level semantics with high-level guarantees: the binary is statically typed, memory limits are explicit, and memory access is isolated. That is why engines validate it before executing, rejecting any instruction that tries to go out of bounds. That validation, together with sandboxed execution, is the foundation of its security.
Linear memory and the wasm module
A wasm program does not see the browser heap. It lives in its own linear memory: a contiguous block of bytes, initially designed for 32 bits (up to 4 GiB), that the module addresses with numeric pointers. To communicate with the outside world it uses imports and exports: it can export functions to JavaScript and, conversely, import functions from the page (for example, to draw on a canvas). The JavaScript↔wasm bridge is thin and fast, designed to pass data in bulk rather than call by call.
When a site loads a .wasm file, the engine runs three phases: decode (parse the binary), validate (check types and memory limits), and compile (generate native code). That flow is supported at runtime by WASI, the interface system for WebAssembly outside the browser, which enables wasm on servers and edge computing, and by the component model, which is unifying modules from different languages so they can interconnect like traditional software pieces.
Threads and SIMD: real performance
What turns wasm into a serious compute platform is its multithreading support: modules that share linear memory and synchronize with atomic operations (atomic). That makes it possible to parallelize work across cores, something JavaScript only achieved in a limited way with web workers (separate threads without shared memory) and data transfer. Alongside multithreading, wasm includes SIMD (single instruction, multiple data) instructions, which process several numbers with a single vector operation, key for matrix math and audio and video codecs.
This combination explains why major products moved their computation cores to wasm. Figma rewrote its rendering engine in C++ compiled to wasm to bring the canvas into the browser without intermediate servers. Machine learning runtimes, such as TensorFlow.js with its WebAssembly backend, run model inference on the user device without sending data to a server. Even entire languages —Python, SQLite, console emulators— run today inside a tab thanks to wasm compilations.
The price you pay
WebAssembly is neither free nor universal. Its linear memory model and rigid typing make it awkward for programs with many dynamic structures, and constant data exchange with JavaScript can become a bottleneck if boundaries are not designed carefully. Moreover, it cannot access the DOM (the page tree) directly; every interaction with the interface goes through JavaScript, adding a layer of indirection.
Evolution continues: the memory64 extension (64-bit) pushes memory beyond the 4 GiB limit, and the GC proposal (garbage collector) will let languages like Java or C# compile to wasm without dragging their own runtime. With WASI maturing for the server, WebAssembly is shaping up as the piece that unifies the browser, the edge, and the backend under a single portable binary: code that travels, is validated, and runs almost as fast as if it were installed on your machine.
