WebAssembly


WebAssembly defines a portable binary-code format and a corresponding text format for executable programs as well as software interfaces for facilitating communication between such programs and their host environment.
The main goal of WebAssembly is to facilitate high-performance applications on web pages, but it is also designed to be usable in non-web environments. It is an open standard intended to support any language on any operating system, and in practice many of the most popular languages already have at least some level of support.
Announced in and first released in, WebAssembly became a World Wide Web Consortium recommendation on 5 December 2019 and it received the Programming Languages Software Award from ACM SIGPLAN in 2021. The W3C maintains the standard with contributions from Mozilla, Microsoft, Google, Apple, Fastly, Intel, and Red Hat.

History

The name "WebAssembly" is intended to suggest bringing assembly language programming to the World Wide Web, where it will be executed client-side, by the website-user's computer via the user's web browser. To accomplish this, WebAssembly must be much more hardware-independent than a true assembly language.
WebAssembly was first announced in 2015, and the first demonstration was executing Unity's Angry Bots in Firefox, Google Chrome, and Microsoft Edge Legacy|Microsoft Edge . The precursor technologies were asm.js from Mozilla and Google Native Client, and the initial implementation was based on the feature set of asm.js.
In March 2017, the design of the minimum viable product was declared to be finished and the preview phase ended. In late September 2017, Safari 11 was released with support. In February 2018, the WebAssembly Working Group published three public working drafts for the Core Specification, JavaScript Interface, and Web API.
The MVP was focused on low-level languages such as C and C++, with the intent to add features useful for high-level languages in a future version.
Multithreading is currently a draft, but has been supported by Chrome since version 75 in June 2019, Firefox version 79, and Safari version 14.1
The WebAssembly 2.0 specification was finished in 2022 and became a W3C standard in December 2024. It adds many SIMD-related instructions and a new v128 datatype, with the ability for functions to return multiple values, mass memory initialize/copy instructions, and reference types, which are opaque pointers to objects outside of the linear memory.
WebAssembly 3.0 was released in September 2025. New features include a 64-bit address space, multiple address spaces, exception handling, and garbage collected struct and array types. Support for garbage collection enables more efficient compilation for languages like C#, F#, and Python.

Implementations

While WebAssembly was initially designed to permit near-native code execution speed in the web browser, it has been considered valuable outside of such, in more generalized contexts. A WebAssembly runtime environment is a low-level virtual stack machine, akin to JVM or Flash VM; it can be embedded into any host application, and thus there have been created standalone WebAssembly runtime environments, including and. WebAssembly runtime environments are embedded in application servers to host "server-side" WebAssembly applications and in other applications to support plug-in-based software extension architectures, e.g., "WebAssembly for Proxies" which specifies a WebAssembly-based ABI for extending proxy servers.

Web browsers

In November 2017, Mozilla declared support "in all major browsers", after WebAssembly was enabled by default in Edge 16. This support also includes mobile web browsers for iOS and Android. 99% of tracked web browsers support WebAssembly, more than for its predecessor asm.js. For some extensions, from the 2.0 draft standard, support may be lower, but still more than 90% of web browsers may already support, e.g. the reference types extension.

Non-browser runtimes

Non-browser WebAssembly runtimes include Wasmer, Wasmtime, WAMR, WAVM, wasm3, and others. These systems execute precompiled Wasm modules and often provide additional APIs for embedding WebAssembly in different environments. Use cases for wasm outside the browser include plug-in interfaces and lightweight virtualization.

Compilers

WebAssembly implementations generally use either ahead-of-time or just-in-time compilation, though some may also use an interpreter. While the first implementations appeared in web browsers, there are now many non-browser implementations for general-purpose use.

Compiler toolchains

Because WebAssembly executables are precompiled, a variety of programming languages can target Wasm. Compilation is achieved either through direct output to Wasm or via intermediate virtual machines implemented in Wasm.
Notable toolchains include:
  • Emscripten, which compiles C and C++ to Wasm using Clang as a frontend, Binaryen as an optimizer, and can also target any LLVM-supported language.
  • Standalone Clang, which supports direct compilation to Wasm.
  • LLVM-based workflows for languages such as Rust and AssemblyScript.

    Language support

As of 2021, around 40 programming languages support WebAssembly as a compilation target. Examples include:
  • C and C++: via Emscripten or Clang standalone.
  • Rust: via rustc with Wasm target.
  • AssemblyScript: a TypeScript-like language compiling directly to Wasm.
  • Go: native WebAssembly support introduced in Go 1.11.
  • .NET languages: C#, F#.
  • Python: implementations such as Pyodide.
  • Java and JVM languages: via CheerpJ, JWebAssembly, and TeaVM.
  • Kotlin: direct Wasm compilation support.
  • Haskell: supported via GHC backend.
  • Julia: community implementations.
  • Ruby: supported through MRuby.
  • Ring: supported with Wasm backend.
  • Dart: supported WebAssembly as a compilation target when building Dart and Flutter applications for the web

    Limitations

s do not permit WebAssembly code to directly manipulate the Document Object Model. Wasm code must defer to JavaScript for this.
In an October 2023 survey of developers, less than half of the 303 participants were satisfied with the state of WebAssembly. A large majority cited the need for improvement in four areas: WASI, debugging support, integration with JavaScript and browser APIs, and build tooling.
For memory-intensive allocations in WebAssembly, there are "grave limitations that make many applications infeasible to be reliably deployed on mobile browsers Currently allocating more than ~300MB of memory is not reliable on Chrome on Android without resorting to Chrome-specific workarounds, nor in Safari on iOS."
All major browsers allow WebAssembly if Content-Security-Policy is not specified, or if the value unsafe-eval is used, but behave differently otherwise; Chrome requires unsafe-eval, though a worker thread can be a workaround.

Security considerations

In June 2018, a security researcher presented the possibility of using WebAssembly to circumvent browser mitigations for Spectre and Meltdown security vulnerabilities once support for threads with shared memory is added. Due to this concern, WebAssembly developers put the feature on hold. However, in order to explore these future language extensions, Google Chrome added experimental support for the WebAssembly thread proposal in October 2018.
WebAssembly has been criticized for allowing greater ease of hiding the evidence for malware writers, scammers and phishing attackers; WebAssembly is present on the user's machine only in its compiled form, which " detection difficult". Speed and the easy ability to conceal in WebAssembly have led to its use in hidden crypto mining within the website visitor's device. Coinhive, a now defunct service facilitating cryptocurrency mining in website visitors' browsers, claims their "miner uses WebAssembly and runs with about 65% of the performance of a native Miner." A June 2019 study from the Technische Universität Braunschweig analyzed the usage of WebAssembly in the Alexa top 1 million websites and found the prevalent use was for malicious crypto mining, and that malware accounted for more than half of the WebAssembly-using websites studied. An April 2021 study from Universität Stuttgart found that since then crypto mining has been marginalized, falling to below 1% of all WebAssembly modules gathered from a wide range of sources, also including the Alexa top 1 million websites.
As WebAssembly supports only structured control flow, it is amenable toward security verification techniques including symbolic execution.

Performance

Early on, the execution speed of a Wasm program was benchmarked to be around 91% of a comparable native program, not including load/instantiation time; however, various later benchmarks indicate a wide range of performance characteristics, from 33% to 200% of the execution speed of native code, depending on the task.
In 2019, a group of researchers from the University of Massachusetts Amherst presented a comprehensive analysis of WebAssembly's performance compared to native code. This study used the SPEC CPU suite of benchmarks and a system called "Browsix-Wasm" to run unmodified Unix applications in the browser, thereby allowing for a test of real-world applications, finding a significant performance gap between Wasm execution and native execution; in particular, Wasm programs showed an average slowdown of 45% in Firefox and 55% in Chrome across the real-world benchmarks; peak slowdowns resulted in a Wasm program taking 2.08 times as long to run in Firefox and 2.5 times as long to run in Chrome. The paper identified several reasons for this performance difference, including missing optimizations, code generation issues in WebAssembly compilers, and inherent limitations of the WebAssembly platform itself.
A 2021 study suggested that WebAssembly is much faster than JavaScript in certain cases, such as running a complex function on a small file ; however, at the time, the JavaScript interpreter had some optimizations available that the WebAssembly implementations did not have.
In 2022, it was determined by researchers that a Wasm program runs at about 120% of the speed of a comparable JavaScript program. Those findings align with the experience of a startup company named "Zaplib", whose founders summarized in a blog that it was shutting down due to lack of performance in WebAssembly. Their goal had been to significantly increase the performance of existing web apps by incrementally porting them to Rust/Wasm; however, porting a customer's simulator from JavaScript yielded only a 5% improvement in performance. Similarly, regarding Figma, they stated the following:
closer inspection it seems that use of Wasm is more due to historical accidents—wanting to build in C++ to hedge for their native app—than for critical performance needs. Figma files are processed in C++/Wasm, and this is likely a huge speedup, but most of Figma's performance magic is due to their WebGL renderer.
In 2023, a study of Wasm's performance for cryptographic tasks indicated that "when using the fastest runtime, WebAssembly was only about 2.32 times slower than native code with architecture-specific optimizations." This result excluded 2 tests where the native code benefited from special instructions implemented directly in the CPU of the target platform; for those particular tests, the Wasm programs were "80 times slower than native code".
Benchmarking has revealed several other pain-points for WebAssembly, such as poor performance because of no direct access to the DOM, a problem which is being addressed.