What Is WebAssembly?

Analogy categoryAnalogies

WebAssembly (Wasm) is a low-level, binary instruction format designed as a portable compilation target for high-level languages such as C, C++, Rust, and Go. Instead of shipping human-readable JavaScript, developers compile existing codebases into a compact .wasm binary that a browser (or other host) can load, validate, and execute at close to native machine speed.

🏏

Cricket analogy: Just as a county cricketer's technique gets 'compiled' into a standardized coaching manual that any franchise coach worldwide can read and apply, Wasm compiles a program written in any language into one binary format any compliant runtime can execute.

Core Design Goals

WebAssembly was designed around four pillars: safety (code runs inside a sandboxed, memory-isolated execution environment with no direct access to the host filesystem or memory), speed (the compact binary is validated and compiled in a single fast pass, enabling near-native performance), portability (execution is deterministic and independent of the underlying hardware or operating system), and openness (the format has a human-readable text representation and was standardized by the W3C with input from all major browser vendors).

🏏

Cricket analogy: Like the DRS (Decision Review System) sandboxing umpiring decisions within strict, auditable rules so no single party can act arbitrarily, Wasm sandboxes code execution so a module cannot reach outside its allotted memory.

The Wasm Binary and Module Format

A compiled .wasm file is organized into a fixed sequence of sections: a type section describing function signatures, an import section listing external dependencies, a function section mapping functions to their types, a memory and table section, a global section, an export section exposing functions to the host, a code section holding the actual instructions, and a data section for initializing linear memory. Hosts parse and validate this structure in a single streaming pass, which is why Wasm can begin executing before the entire file has even finished downloading.

🏏

Cricket analogy: Like a scorecard broken into fixed sections — batting order, bowling figures, fall of wickets — that a scorer can fill in as the innings progresses without waiting for the match to finish, Wasm's sections let a host start parsing while the file streams.

wat

(module
  (func $add (param $a i32) (param $b i32) (result i32)
    local.get $a
    local.get $b
    i32.add)
  (export "add" (func $add)))

Where WebAssembly Runs

WebAssembly began as a browser technology, implemented in V8 (Chrome, Node.js), SpiderMonkey (Firefox), and JavaScriptCore (Safari), where it runs alongside JavaScript in the same sandboxed page context. It has since expanded far beyond the browser: standalone runtimes like Wasmtime, Wasmer, and WasmEdge execute .wasm modules on servers and edge nodes, often using the WASI (WebAssembly System Interface) standard to grant controlled access to files, clocks, and networking outside the browser sandbox.

🏏

Cricket analogy: Like a bowling action first perfected in domestic Ranji Trophy cricket and later adapted for T20 franchise leagues around the world, Wasm started in the browser and has since spread to servers and edge runtimes.

WASI (WebAssembly System Interface) is what lets a .wasm module read files, use clocks, or open sockets outside the browser sandbox — without WASI, a standalone Wasm module has no way to touch the outside world.

WebAssembly (Wasm) is a portable, low-level binary instruction format, not a programming language itself.
It is designed around four pillars: safety (sandboxing), speed (near-native execution), portability, and openness.
Languages like C, C++, Rust, and Go compile to .wasm; developers rarely write raw Wasm by hand.
A .wasm module is organized into ordered sections (type, import, function, memory, export, code, data) that enable streaming compilation.
Wasm originally ran only in browsers (V8, SpiderMonkey, JavaScriptCore) alongside JavaScript.
Standalone runtimes (Wasmtime, Wasmer, WasmEdge) now run Wasm outside the browser using the WASI system interface.
Because it is sandboxed and deterministic, the same Wasm binary behaves identically across very different host environments.