WebAssembly

WebAssembly defines a compact binary format and an associated text representation called WAT. Its abstract machine uses a stack-based evaluation model, structured control flow, typed values, functions, tables, and linear memory rather than exposing a particular processor's instruction set.¹ The original minimum viable product, or MVP, centered on four numeric types: 32-bit and 64-bit integers and 32-bit and 64-bit floating-point values.

The format is language-neutral: compilers can target it from C, C++, Rust, AssemblyScript, and other languages. A WebAssembly module does not by itself define file access, networking, graphics, or an operating-system interface. Those capabilities are supplied by its host through imports and exports, which keeps the core specification small and makes the same module adaptable to browsers, servers, plug-ins, and embedded runtimes.²

Web browsers compile or interpret WebAssembly modules inside a sandboxed execution environment, usually alongside JavaScript. A module is decoded, validated against the type rules, instantiated with selected imports, and then invoked through exported functions.³ Its binary encoding is intended to be smaller and faster to process than a comparable textual source program, although actual performance depends on compilation strategy, memory behavior, host calls, and the source language.

WebAssembly and JavaScript interoperate through explicit boundaries rather than shared language semantics. JavaScript can create memories, tables, and module instances, while WebAssembly can call imported host functions. The WebAssembly JavaScript API exposes these operations, and the WebAssembly System Interface, or WASI, provides a separate family of standardized host interfaces for non-browser environments.⁴ This separation prevents the core format from becoming tied to the browser.

WebAssembly's security model is based on validation, isolation, and explicit capabilities. A module cannot directly perform arbitrary system calls or address host memory; it operates within resources provided by the embedding environment, commonly including a bounds-checked linear memory and imported functions.¹ These properties make it useful for running partially trusted code, but they do not make every module automatically safe: vulnerabilities in the compiled program, its libraries, the host, or imported capabilities can still create risks.

Portability also has boundaries. Floating-point behavior, threading support, available host APIs, resource limits, and compiler assumptions can affect results across environments. WebAssembly is therefore a virtual instruction format, not a complete application platform. Programs that rely on WASI, browser APIs, or a particular runtime require those interfaces to be present and compatible. The WebAssembly specification is developed through a standards process under the World Wide Web Consortium, with proposals extending the core in stages.²

WebAssembly has expanded beyond its original browser-focused MVP through separately standardized or proposed features. SIMD instructions can accelerate data-parallel work; threads and shared memory support selected concurrent workloads; and reference types allow stronger interaction with host-managed objects. The garbage-collection proposal is aimed at making languages with managed runtimes more natural compilation targets, while exception-handling features reduce the need to encode all control transfer manually.⁵

Another important development is the WebAssembly Component Model, which seeks to make independently built modules easier to compose through typed interfaces and language-neutral data exchange. Components build on interface descriptions rather than treating raw numeric imports and memory layouts as the only integration mechanism.⁶ WebAssembly is consequently used in edge computing, plug-in systems, serverless infrastructure, scientific tools, and developer tools as well as in browser applications.

WAT

The human-readable text format for representing WebAssembly modules and instructions.

Linear memory

A contiguous, byte-addressable memory exposed to a module and grown according to host and module rules.

WASI

The WebAssembly System Interface, a collection of host APIs intended primarily for WebAssembly outside browsers.

Component Model

A developing WebAssembly composition model for connecting modules through typed, language-neutral interfaces.