What Is WebAssembly (Wasm)? How It Works

WebAssembly, almost always shortened to "Wasm," is officially defined by its own standards body as "a binary instruction format for a stack-based virtual machine." In plainer terms: it's a compact, fast-loading compiled format that lets programs written in languages other than JavaScript run on the web — and, increasingly, outside the browser entirely. If you've used a browser-based version of a heavyweight creative app, played a demanding game in a browser tab without installing anything, or loaded a page that felt suspiciously fast for how much it was doing, there's a reasonable chance WebAssembly was doing some of the work behind the scenes.

What Is WebAssembly?

According to WebAssembly.org, the technology's own standards site, WebAssembly is designed as "a portable compilation target for programming languages," meaning developers write code in a language like C, C++, Rust or Go, and a compiler turns it into the Wasm binary format instead of (or alongside) a platform-specific executable. The W3C — the standards body that also oversees HTML and CSS — made WebAssembly an official Web Recommendation in December 2019, putting it alongside JavaScript and HTML as one of the core technologies of the web platform.

WebAssembly was developed jointly by engineers from Mozilla, Google, Microsoft and Apple, and shipped simultaneously in Firefox, Chrome, Edge and Safari starting in 2017 — a notably coordinated launch for a new web technology, reflecting that all four major browser engines needed to implement the same binary format for it to be useful on the open web at all.

WebAssembly.org lists four defining design goals: it aims to execute at native speed by taking advantage of common hardware capabilities; it's designed to be safe, running in a memory-safe, sandboxed execution environment that, inside a browser, follows the same security rules (like same-origin policy) as JavaScript; it's open and debuggable, with a human-readable text format alongside its binary one; and it's built to target the existing web platform, so Wasm modules can call JavaScript and use the same web APIs JavaScript already has access to.

Why Not Just Use JavaScript?

WebAssembly isn't a replacement for JavaScript — it's explicitly designed to run alongside it. JavaScript remains a dynamically typed, interpreted-then-JIT-compiled language optimized for flexibility and rapid development. WebAssembly instead gives the web a compact, statically typed binary format that a browser can parse and start executing far faster than it can for an equivalent amount of JavaScript text, which matters most for computationally heavy work: video and image editing, 3D rendering, physics simulation, encryption, or porting an existing large C/C++ codebase to run in a browser tab without rewriting it from scratch.

In practice, most real-world Wasm use is JavaScript calling into a Wasm module for the expensive part of a task, then using the result back in ordinary JavaScript and the DOM — not a web page built entirely in WebAssembly instead of JavaScript. Wasm also has no direct access to the DOM on its own; a Wasm module reads and writes the page through the same JavaScript APIs a developer would otherwise call directly, which is one more reason it's accurate to describe Wasm as JavaScript's companion rather than its replacement.

WebAssembly vs. JavaScript

WebAssembly Outside the Browser

WebAssembly.org's own description notes it also supports "non-web embeddings," and this is where a lot of Wasm's recent growth has happened. Standalone Wasm runtimes — such as Wasmtime, Wasmer and WasmEdge — let the same sandboxed, portable binary format run as a lightweight alternative to a full container or virtual machine for server-side and edge computing, plugin systems, and serverless functions. The appeal is the same sandboxing and portability that makes Wasm safe inside a browser tab: a Wasm module compiled once can run unmodified across different operating systems and CPU architectures, inside a security boundary that limits what it can access by default.

The WebAssembly System Interface (WASI) extends this further, standardizing how a Wasm module outside a browser can request access to things like the filesystem or network in a controlled, capability-based way — giving non-web Wasm a standard way to interact with its host system without each runtime inventing its own incompatible APIs.

Which Languages Compile to WebAssembly?

• Rust has official, first-class support for compiling to WebAssembly, and the Rust toolchain is commonly cited as one of the most ergonomic ways to target Wasm today.
• C and C++ can compile to WebAssembly using Emscripten, a toolchain built specifically to port existing native codebases to the web.
• Go has built-in support for compiling to WebAssembly as one of its standard target platforms.
• Additional languages — including C#, Kotlin and Python-to-Wasm projects — have growing but less mature Wasm toolchains, reflecting how new some of this tooling still is relative to decades-old native compilers.

What all of these toolchains share is the same output target: a .wasm binary file that any Wasm-capable runtime can execute, whether that runtime is a browser's JavaScript engine or a standalone server-side runtime. A developer doesn't need to know or care which language produced a given .wasm module to run it — the format itself is the interoperability layer, the same way a browser doesn't need to know what language a JPEG decoder was written in to display an image.

Real-World Uses of WebAssembly

• Bringing existing native software to the browser. Figma and AutoCAD's web versions are commonly cited examples of large, performance-sensitive native applications ported to run inside a browser tab using Wasm — software with years of optimized C++ behind it, made to run in a tab rather than rewritten in JavaScript from scratch.
• Browser-based games and creative tools. Game engines and video/audio editing tools compiled to Wasm bring near-native rendering and processing performance to the browser without requiring a plugin like the long-discontinued Flash or Java applets once did.
• Edge and serverless computing. Platforms including Cloudflare Workers and Fastly's Compute use Wasm sandboxes to start untrusted, customer-submitted code in milliseconds, which is fast enough to run a sandbox per incoming request rather than keeping a pool of warm containers running.
• Plugin systems. Some applications now let users write plugins in any language that compiles to Wasm, then run those plugins in a sandbox that limits what they can touch on the host system — getting the flexibility of user-supplied code without giving that code unrestricted system access.

Is WebAssembly Safe?

WebAssembly.org's own design goals describe the format as running in a "memory-safe, sandboxed execution environment." Inside a browser, a Wasm module is bound by the same security model as JavaScript — it can't access the filesystem or make arbitrary network requests on its own, and it's subject to the same same-origin policy. Outside the browser, WASI's capability-based model means a standalone Wasm module only gets access to the specific files, network sockets or other resources its host explicitly grants it, rather than inheriting the full permissions of the process running it — which is a meaningfully narrower default than a typical native executable gets.

That sandboxing is precisely why Wasm has become attractive for running untrusted, third-party code safely: a plugin or a customer-submitted function compiled to Wasm can be given exactly the access it needs — and nothing more — by the host application, without relying on the plugin author's code to behave well on its own. This is a meaningfully different trust model than loading a native plugin or extension, which traditionally runs with the same permissions as the host application itself unless the host does extra work to sandbox it.

WebAssembly vs. Containers

Standalone WebAssembly runtimes are frequently compared to Docker containers, since both aim to run the same packaged code consistently across different machines. The difference is mostly in weight and startup time: a container packages an application together with an operating system userland, which gives it broad compatibility but a heavier footprint and a startup measured in hundreds of milliseconds to seconds. A Wasm module skips packaging an OS entirely — it's sandboxed by the runtime itself — which is why cold starts for a Wasm module are commonly measured in single-digit milliseconds, fast enough to start a fresh sandboxed instance per request rather than keeping one running and reusing it. That tradeoff is also why Wasm and containers are frequently used together rather than as strict alternatives, with some container orchestration tooling now adding Wasm support alongside its existing container runtime.

JavaScript runtimes have followed the same trend. Both Node.js and newer runtimes like Bun and Deno can load and execute WebAssembly modules directly, which means a performance-critical library — an image codec, a compression algorithm, a cryptography routine — can be written once in Rust or C++, compiled to Wasm, and called from JavaScript running in any of those runtimes without needing a separate native build for each one.

How to Try WebAssembly

1. In the browser: modern versions of Chrome, Firefox, Safari and Edge all support WebAssembly natively — no plugin or flag is required to run a Wasm module today.
2. To compile your own: Rust developers can target Wasm directly via the wasm32-unknown-unknown or wasm32-wasi compilation targets; C/C++ developers typically use the Emscripten toolchain.
3. To run Wasm outside a browser: install a standalone runtime such as Wasmtime or Wasmer to execute a .wasm file directly from the command line.

What's Next

WebAssembly's growth path has gone from "make heavy web apps faster" to "a portable, sandboxed binary format for running code almost anywhere" — browsers, edge networks, plugin systems and serverless platforms alike. For developers deciding what to build with, the practical takeaway from WebAssembly.org's own framing is that Wasm isn't competing with JavaScript for most day-to-day web development; it's a companion format for the specific, computationally heavy slice of a project where near-native speed and a small, fast-loading binary actually matter.

The standards work also hasn't stopped at the 2019 Web Recommendation. The WebAssembly Community Group continues developing proposals that extend what Wasm can do — garbage-collected language support, multi-threading, and tighter integration with the component model that lets Wasm modules written in different languages interoperate more cleanly — so the format's capabilities outside its original "fast code in the browser" use case keep expanding.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage