Who Develops and Maintains the WebAssembly Standard?

WebAssembly's open standards are developed in a W3C Community Group that includes representatives from all major browsers, and also in a W3C Working Group. The official site, webassembly.org, describes this structure directly and points visitors to a Community section for participation and news. In short: the standard is a multi-vendor, open-standards effort under the W3C umbrella rather than a single company's proprietary specification.

How the Standard Is Organized

The site's overview states that "the open standards for WebAssembly are developed in a W3C Community Group (that includes representatives from all major browsers) as well as a W3C Working Group." That sentence carries most of what you need to know about governance:

Two things follow from this. First, browser vendors participate in the Community Group, which is consistent with the site's claim that WebAssembly is "part of the open web platform" and maintains the web's "versionless, feature-tested, and backwards-compatible nature." Second, because standards work happens in W3C groups, the specification is not controlled by any one runtime or vendor.

What the Site Provides Beyond Governance

webassembly.org is the project's public entry point, not the specification text itself. Its navigation covers Overview, Getting Started, Specs, Docs, Feature Status, Community, and News. For developer reference documentation, the site directs readers to MDN's WebAssembly pages. So if you want the normative standard, follow the Specs link; if you want to track what is shipping, use Feature Status.

Why This Structure Matters in Practice

The governance model explains several properties the site advertises:

• Portability. Wasm is described as "a portable compilation target for programming languages, enabling deployment on the web for client and server applications." A cross-vendor standard is what makes one compiled module runnable across environments.
• Safety by design. The site describes "a memory-safe, sandboxed execution environment that may even be implemented inside existing JavaScript virtual machines," and notes that when embedded in the web it enforces the browser's same-origin and permissions security policies. These are standard-level commitments, not features of one engine.
• Openness and debuggability. Wasm is designed to be pretty-printed in a textual format for debugging, testing, experimenting, optimizing, learning, teaching, and writing programs by hand, and that textual format is used when viewing the source of Wasm modules on the web.
• Non-web embeddings. The site notes that WebAssembly also supports non-web embeddings, which is why the standard is not scoped only to browsers.

A concrete example of why the multi-party process matters: a feature such as a new instruction or a change to how modules interact with JavaScript has to be agreed among browser representatives in the Community Group before it can be relied on across engines. That is also why the site emphasizes "feature-tested" compatibility and maintains a Feature Status page — you check what is implemented rather than assuming a version number guarantees support.

How to Follow or Join the Work

If your goal is to track or contribute to the standard rather than just use it:

1. Start at webassembly.org and open the Community section for participation channels and news.
2. Use Specs for the standards documents and Feature Status to see where features stand.
3. Use Docs (or the linked MDN WebAssembly pages) for developer-facing reference.
4. If you intend to contribute, the relevant venues are the W3C Community Group and Working Group named on the site — participation there is how browser representatives and other contributors shape the standard.

A common sticking point: people look for a single "owner" of WebAssembly and a version number to pin against. The site's framing points the other way — the standard is maintained through W3C groups with major-browser representation, and compatibility is handled by feature testing rather than versioning. Plan your tooling and support decisions around feature status, not around a release number.