Introduction

WebAssembly (abbreviated Wasm [1]) is a safe, portable, low-level code format designed for efficient execution and compact representation. Its main goal is to enable high performance applications on the Web, but it does not make any Web-specific assumptions or provide Web-specific features, so it can be employed in other environments as well.

WebAssembly is an open standard developed by a W3C Community Group.

This document describes version 2.0 (Draft 2024-12-18) of the core WebAssembly standard. It is intended that it will be superseded by new incremental releases with additional features in the future.

Design Goals

The design goals of WebAssembly are the following:

• Fast, safe, and portable semantics:

  • Fast: executes with near native code performance, taking advantage of capabilities common to all contemporary hardware.

  • Safe: code is validated and executes in a memory-safe [2], sandboxed environment preventing data corruption or security breaches.

  • Well-defined: fully and precisely defines valid programs and their behavior in a way that is easy to reason about informally and formally.

  • Hardware-independent: can be compiled on all modern architectures, desktop or mobile devices and embedded systems alike.

  • Language-independent: does not privilege any particular language, programming model, or object model.

  • Platform-independent: can be embedded in browsers, run as a stand-alone VM, or integrated in other environments.

  • Open: programs can interoperate with their environment in a simple and universal manner.

• Efficient and portable representation:

  • Compact: has a binary format that is fast to transmit by being smaller than typical text or native code formats.

  • Modular: programs can be split up in smaller parts that can be transmitted, cached, and consumed separately.

  • Efficient: can be decoded, validated, and compiled in a fast single pass, equally with either just-in-time (JIT) or ahead-of-time (AOT) compilation.

  • Streamable: allows decoding, validation, and compilation to begin as soon as possible, before all data has been seen.

  • Parallelizable: allows decoding, validation, and compilation to be split into many independent parallel tasks.

  • Portable: makes no architectural assumptions that are not broadly supported across modern hardware.

WebAssembly code is also intended to be easy to inspect and debug, especially in environments like web browsers, but such features are beyond the scope of this specification.

[1]

A contraction of “WebAssembly”, not an acronym, hence not using all-caps.

[2]

No program can break WebAssembly’s memory model. Of course, it cannot guarantee that an unsafe language compiling to WebAssembly does not corrupt its own memory layout, e.g. inside WebAssembly’s linear memory.

Scope

At its core, WebAssembly is a virtual instruction set architecture (virtual ISA). As such, it has many use cases and can be embedded in many different environments. To encompass their variety and enable maximum reuse, the WebAssembly specification is split and layered into several documents.

This document is concerned with the core ISA layer of WebAssembly. It defines the instruction set, binary encoding, validation, and execution semantics, as well as a textual representation. It does not, however, define how WebAssembly programs can interact with a specific environment they execute in, nor how they are invoked from such an environment.

Instead, this specification is complemented by additional documents defining interfaces to specific embedding environments such as the Web. These will each define a WebAssembly application programming interface (API) suitable for a given environment.

Security Considerations

WebAssembly provides no ambient access to the computing environment in which code is executed. Any interaction with the environment, such as I/O, access to resources, or operating system calls, can only be performed by invoking functions provided by the embedder and imported into a WebAssembly module. An embedder can establish security policies suitable for a respective environment by controlling or limiting which functional capabilities it makes available for import. Such considerations are an embedder’s responsibility and the subject of API definitions for a specific environment.

Because WebAssembly is designed to be translated into machine code running directly on the host’s hardware, it is potentially vulnerable to side channel attacks on the hardware level. In environments where this is a concern, an embedder may have to put suitable mitigations into place to isolate WebAssembly computations.

Dependencies

WebAssembly depends on two existing standards:

• IEEE 754, for the representation of floating-point data and the semantics of respective numeric operations.

• Unicode, for the representation of import/export names and the text format.

However, to make this specification self-contained, relevant aspects of the aforementioned standards are defined and formalized as part of this specification, such as the binary representation and rounding of floating-point values, and the value range and UTF-8 encoding of Unicode characters.

Note

The aforementioned standards are the authoritative source of all respective definitions. Formalizations given in this specification are intended to match these definitions. Any discrepancy in the syntax or semantics described is to be considered an error.