Two worlds that could not be more different live on the web. One is JavaScript, the language behind most of the sites you visit. The other is binaries: compiled programs that the browser executes directly, almost at the speed of a native application. That second world has a name: WebAssembly, and its story explains why you can now run Photoshop or a game engine inside a browser tab.
The problem WebAssembly came to solve
JavaScript had an invisible ceiling for years. Even though modern engines such as V8 (Chrome and Node.js) or SpiderMonkey (Firefox) speed it up with JIT compilation (just-in-time: code is translated to machine instructions at runtime), that path has a cost. The engine starts by interpreting, then compiles on the fly, and peak performance only arrives after a warm-up that can last seconds.
JavaScript is also a dynamically typed language: the engine does not know whether a variable is a number or a string until it sees it running, which forces constant type checks. For heavy applications —a design editor, a 3D viewer, an office suite— the browser fell short. The answer was not making JavaScript faster, but offering an alternative route: a binary format designed for predictable compilation.
What WebAssembly actually is
WebAssembly (wasm for short) is a bytecode format: a compact intermediate code that belongs to no real processor, but to an abstract machine. It was designed between 2015 and 2019 by engineers from Mozilla, Google, Microsoft and Apple, and in December 2019 it became an official W3C recommendation, the standard body of the web. Every major browser has run it since 2017.
A wasm module is organised into sections: types, functions, memory and imports. Instructions are encoded with LEB128 numbers (variable-length integers: integers that take fewer bytes the smaller they are), which keeps binaries very compact. Execution follows a stack machine model: operations take their operands from a stack and leave the result on it, just like classic CISC CPUs or the Java JVM.
You do not write wasm to produce wasm. You write in C, C++, Rust or Go, and a compiler based on LLVM (the open-source compiler infrastructure also used by Clang) translates it into the binary format. That same model means one source can be compiled once and run on any browser, without rewriting anything.
Memory and isolation: the part nobody sees
The heart of wasm’s security is its memory model. Each module receives a linear memory: a huge contiguous block of bytes, up to 4 GiB, where its data lives. The module can only read and write inside that block; any out-of-bounds access is checked and rejected at runtime with a trap.
There are no pointers to the outside. If a wasm program wants to do anything beyond its memory —draw a pixel, read a file— it must ask through imports: functions that the host (the browser, or a server) hands to it explicitly. It is a capability model: the module can only do what it has been given, nothing more. The system also enforces W^X (write XOR execute): memory is either writable or executable, never both at once, which cuts off many classic code-injection attacks at the root.
That combination —strict isolation and static verification of the binary before running it— is what allows potentially hostile code to run in a tab without putting the rest of the system at risk.
How it runs: two tiers for the best of both worlds
Engines execute wasm with a two-tier strategy. First a baseline compiler (called Liftoff in V8) translates the bytecode into machine code almost instantly, so the app starts in milliseconds; then, while the program runs, an optimising compiler (TurboFan in V8) recompiles the most used functions with aggressive optimisations. In practice, a wasm module performs at between 80% and 95% of a native application, with a fraction of JavaScript’s startup time.
Outside the browser there are dedicated engines: Wasmtime (from the Bytecode Alliance foundation, using the Cranelift compiler), Wasmer or WasmEdge. They are the foundation of the new generation of edge computing (running code near the user, on a CDN’s servers). Content delivery companies such as Fastly or Cloudflare run hundreds of thousands of functions per second from different customers, isolated from each other inside the same process, without booting a container or a virtual machine per request.
WASI and the road to a universal runtime
For wasm to work outside the browser, more than the format was needed: an interface with the operating system. That is WASI (WebAssembly System Interface), a specification that defines file, socket and clock operations, similar in spirit to POSIX but secure by design. Thanks to WASI, the same binary that runs in a browser can run on a server, a serverless function or even a microcontroller.
Important extensions have also arrived: threads (with shared memory and atomic operations), SIMD (Single Instruction, Multiple Data: running one operation on several pieces of data at once, key for multimedia and AI), garbage collection support for managed languages, and the component model, which lets you compose modules from different languages as if they were LEGO bricks.
Where it is used today
Real use cases are the best proof that this is not a laboratory technology. Figma, the collaborative design tool, compiles its C++ engine to wasm so a canvas with a hundred thousand objects moves smoothly. Photoshop Web, Google Earth and the exporters of Unity, Unreal and Godot do the same. Even SQLite, the most widely used embedded database in the world, has an official wasm build that runs inside the browser.
And there is a new application accelerating everything: AI in the browser. Libraries such as Transformers.js or WebLLM run language models directly in the tab, without sending your data to any server, taking advantage of linear memory, SIMD and, soon, WebGPU to accelerate matrix operations. The same executable that powered the games of 2019 is today the foundation of a ChatGPT that lives on your machine.
What it means for the future of the web
WebAssembly is not going to kill JavaScript: both coexist, and the latter remains the glue driving the interface. But the balance of power has shifted. When the execution format no longer belongs to a single language, the web becomes an open platform where any ecosystem can have first-class citizenship: you take years of C++ code into a tab without rewriting, with security isolation and near-native performance.
In 2026, every time you open a heavy document, a photo editor or an AI model inside the browser, you are probably using it without knowing. The executable that came to stay is no longer a curiosity: it is the invisible infrastructure of the modern web.
