WebAssembly (or Wasm for short) is a low-level binary format that browsers can execute at near-native speed. It was born with a concrete promise: that a web application could run as fast as an installed one, without installing anything.
Until a few years ago, the browser only understood JavaScript. For demanding performance, JavaScript has a ceiling: as an interpreted, dynamic language, the engine has to figure out types at runtime. WebAssembly changes the rules by delivering a binary that the browser can interpret without ambiguity.
How a Wasm binary works
A program written in C, C++ or Rust is compiled to Wasm using a compiler with a WebAssembly backend (such as LLVM). The result is a .wasm file, a compact set of instructions that are statically typed: the type of every operation is known in advance, with no need for hot-path inference. That lets the engine generate optimized machine code far more predictably.
Wasm modules run on a stack machine: each instruction pushes or pops values onto an operand stack. There are no explicit registers as in x86 or ARM; the stack acts as working memory and vastly simplifies code validation.
Linear memory and the sandbox
A module never accesses the system RAM directly. Instead it gets a linear memory: a single contiguous byte array, typically starting at 64 kib and growable in 64 kib pages. Any access outside its bounds immediately triggers a trap, which prevents whole classes of classic buffer overflows at the root.
This architecture is the basis of its sandbox model: the code cannot make system calls on its own. To read a file, make a network request, or touch the DOM, it must import functions from the host (the JavaScript runtime). It is the browser itself that decides which capabilities to expose.
Numeric types and the road to extensions
Wasm 1.0 supports four numeric types: 32- and 64-bit integers (i32, i64) and 32- and 64-bit floating point (f32, f64). On top of that base, the standards group (W3C) has been adding proposals. The most anticipated is reference types with garbage collection (GC), which allows high-level data types and closures without copying between JavaScript and Wasm.
Also notable are SIMD (instructions that process data in parallel) to accelerate multimedia, and multithreading with shared memory (SharedArrayBuffer), which enables workers that share data at high speed.
Where it is really used
The most visible case is in-browser rendering: tools such as Figma run their design engine in Wasm, and editors like VS Code use the web version of language servers compiled to Wasm to offer near-native autocompletion. Compressors, video codecs, console emulators and computer-vision libraries (OpenCV.js) also depend on it.
Outside the browser, the WASI ecosystem (WebAssembly System Interface) defines an operating-system access layer (files, sockets, environment variables) that lets the same binary run on servers. Edge-computing platforms and serverless providers use it because a module starts in milliseconds and isolates each request without the overhead of a full container.
A way to package portable compute
WebAssembly is not here to replace JavaScript: it complements it for the parts where performance or code reuse really matter. It is, in essence, a neutral software-distribution format that runs in browsers, servers and embedded devices with the same security guarantee and the same speed.
