# WebAssembly/spec: the specification source, reference interpreter and test suite > The WebAssembly/spec repository holds the normative specification sources, a reference interpreter used to run the official test suite, and the test corpus itself. It is a working repository for people who implement Wasm engines or change the standard, not a place to learn WebAssembly from scratch. **WebAssembly/spec** — WebAssembly specification, reference interpreter, and test suite. - Repository: https://github.com/WebAssembly/spec - Website: https://webassembly.github.io/spec/ - Stars: 3,456 · Forks: 540 - Language: WebAssembly - License: NOASSERTION - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/webassembly-spec ## What WebAssembly/spec is, and what it is not This repository is the source of the WebAssembly specification, together with a reference implementation and the official test suite. The README states that plainly: it holds "the sources for the WebAssembly specification, a reference implementation, and the official test suite." A formatted version is published at webassembly.github.io/spec. The audience follows from that. If you are implementing a Wasm engine, adding a proposal, or verifying that your runtime matches the standard, this is the upstream source you compare against. If you want to compile Rust to Wasm and ship it in a browser, this repository is the wrong entry point; nothing here is a build tool or a runtime you would embed in a product. The top-level layout confirms the split: document/ and specification/ hold the specification material, interpreter/ holds the reference implementation, test/ holds the test suite, proposals/ collects proposal work, and spectec/ holds the Spectec tooling that the CI badges reference. The README also names papers/ and wasm-specs.bib, the latter provided for LaTeX citations. The project is not archived, and the last push was on 2026-09-22, so the repository is being maintained. ## How the pieces fit: document, interpreter, test suite, spectec The repository is organised as a pipeline rather than a single artifact. The specification sources live under document/ and specification/, and the published HTML at webassembly.github.io/spec is generated from them. The interpreter/ directory contains the reference interpreter, which exists so that the test suite has something to execute against. The test/ directory holds that suite. Three separate CI workflows guard these parts, and the README shows their badges: ci-spec.yml for the spec document, ci-interpreter.yml for the interpreter and tests, and ci-spectec.yml for Spectec. That separation matters when you are debugging a failure. A red badge on ci-spec means the specification sources or their build are broken; a red badge on ci-interpreter means the reference interpreter or the test suite is failing. Treating the repository as one monolithic build will send you looking in the wrong directory. The .gitmodules file at the top level indicates that at least one component is pulled in as a submodule, so a clone that skips submodules will not reproduce the full layout. The proposals/ directory is where changes that are not yet part of the core standard accumulate, which is consistent with the README's instruction that substantial discussion belongs in the design repository first. ## Building the spec and running the reference interpreter The README does not document an install procedure, a package name, or a supported toolchain. It points to the formatted specification site and to Contributing.md for contribution guidelines. The one concrete instruction it gives is about where to take discussion, not about how to build. So the honest starting point is a clone of the repository, followed by reading the build files inside document/ and interpreter/ rather than guessing at commands. A shallow clone with submodules is the layout-preserving option: ```bash git clone --recurse-submodules https://github.com/WebAssembly/spec.git cd spec ``` The --recurse-submodules flag matters because .gitmodules is present at the top level. Without it you get a checkout that does not match the repository as published. From there, inspect the directories before running anything: ```bash ls document interpreter test spectec ``` Each of those directories carries its own build or run instructions in its own files; the root README does not restate them. If your goal is to check an engine rather than to build the spec, the test/ directory is the artifact you want, and the interpreter is the thing the suite is designed to run against. Expect to spend your first hour reading build files, not following a quickstart. ## The interpreter is a reference, not a production runtime A reference interpreter has one job: to define behaviour precisely enough that other implementations can be compared against it. That job is different from being fast, embeddable, or hardened. The repository describes interpreter/ as a reference implementation, and the CI workflow name ci-interpreter.yml ties it to the test suite rather than to any deployment story. If you are choosing a runtime to ship in a browser, a serverless platform, or an embedded device, this is the wrong tool, and the README offers no performance guidance that would suggest otherwise. The second limitation is scope. The README is explicit that participation is welcome but that "discussions about new features, significant semantic changes, or any specification change likely to generate substantial discussion should take place in the WebAssembly design repository first, so that this spec repository can remain focused." That is a deliberate constraint on the issue tracker: a feature request filed here may be redirected rather than answered. The third is documentation. There are no release notes in the repository, and the README does not describe versioning, rollback, or upgrade paths for the specification itself. If you need a stable, versioned artifact to pin against, the repository does not advertise one here. ## How this differs from an engine implementation like Wasmtime or Wasmer The obvious alternative for most readers is a standalone engine such as Wasmtime or Wasmer. The difference is not quality, it is purpose. An engine is a product: it ships binaries, a CLI, language bindings, and release notes, and its documentation is written for people who want to run Wasm today. WebAssembly/spec is the thing those engines are measured against. Its interpreter exists to execute the official test suite, and its test suite is the conformance corpus an engine author runs to find out where their implementation diverges from the standard. If you want to execute Wasm in an application, an engine is the right dependency. If you want to know whether an engine is correct, or you are writing one, the spec repository is the reference point, and the two roles do not substitute for each other. The same distinction applies to the specification documents: the published HTML at webassembly.github.io/spec is for reading, while document/ and specification/ are for editing and rebuilding. Related search terms people use, such as "Wasm 2.0 spec" or "webassembly spec pdf", point at the reading side of that split rather than at the interpreter. ## Licence, citation and the cost of tracking the standard The repository metadata reports the licence as NOASSERTION, which means no recognised SPDX identifier was detected. The LICENSE file is present at the top level, so the terms are stated there, but anyone planning to redistribute specification text, test cases, or interpreter code should read that file rather than assume a permissive default. This is a description of what the repository contains, not legal advice. On the citation side, the README is unusually direct: for citing WebAssembly in LaTeX, it points to wasm-specs.bib at the top level. That is a small but real convenience for academic work, and it is the only usage instruction the README gives beyond the contributing pointer. The maintenance cost is the part people underestimate. Because this repository tracks a standard rather than a product, there is no version number in the README to pin to and no changelog in the repository. An engine author who wants to stay conformant has to follow the test suite and the specification sources as they change, and re-run conformance when they do. That is ongoing work, not a one-time integration, and the three CI workflows shown in the README are the signal to watch for movement. ## Conclusion Adopt it if you are writing or auditing a WebAssembly engine, or if you need the official test suite to check conformance. Do not adopt it as an application framework or as a tutorial: the repository is a specification project, and the README points newcomers to the formatted spec site rather than to a getting-started guide. Before relying on anything here, check the LICENSE file, because the repository metadata reports NOASSERTION rather than a recognised identifier, and read Contributing.md before proposing a change, since the README states that new features and significant semantic changes should be discussed in the WebAssembly design repository first. ## FAQ ### What exactly is WebAssembly? The README describes this repository as holding the sources for the WebAssembly specification, a reference implementation, and the official test suite, and points to webassembly.github.io/spec for a formatted version of the spec. It does not go further than that in defining the technology. ### Is WebAssembly still relevant? The repository is not archived, and the last push was on 2026-09-22, so work on the specification sources, the reference interpreter and the test suite is ongoing. The repository contains no adoption or usage data that would answer the relevance question more broadly. ### Is Wasm really faster than js? The repository contains no performance claims or benchmarks, so this cannot be answered from it. The README describes the interpreter as a reference implementation and gives no execution speed figures. ## Sources - [Issues](https://github.com/WebAssembly/spec/issues) - [Project website](https://webassembly.github.io/spec/) - [README](https://github.com/WebAssembly/spec/blob/main/README.md) - [WebAssembly/spec on GitHub](https://github.com/WebAssembly/spec) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/webassembly-spec