The WebAssembly threads proposal and where its sources live

A proposal working tree, not a library you import

The first thing to settle is what kind of artefact this is. The WebAssembly/threads repository holds the sources of a proposal to add threads support to WebAssembly, and it is described as a clone of github.com/WebAssembly/spec. The stated purpose is discussion, prototype specification and implementation of that proposal.

That is three activities in one sentence, and the repository is shaped for all of them. It is a place where the wording of a standard gets argued over, where a prototype of that wording gets written down, and where the implementation work happens. The repository description in the project listing is simply Threads and Atomics in WebAssembly, and the topic tag attached to the repository is proposal.

So who is it for? People implementing WebAssembly engines or toolchains who need to know what the threads proposal currently says, people writing applications against a future threads-enabled WebAssembly and who need to track the design, and contributors who want to help shape the standard before it settles. If you are an application developer today, none of this is a dependency you can install. There is no package name, no version you pin, and no runtime here.

The one part you can consume without any tooling is the published specification text.

The top level tells you what the working tree contains

The repository listing is short enough to be worth reading closely, because each entry tells you something about the workflow. There is a document/ directory, which in a specification repository holds the spec sources. There is an interpreter/ directory, which is the reference implementation the upstream repository describes as part of what it holds. There is a test/ directory, corresponding to the official test suite.

Then there are the directories that are specific to proposal work. proposals/ holds the proposal documents themselves, and the README points into it for the threads overview at proposals/threads/Overview.md. papers/ holds the accompanying papers, the kind of document that argues for a design in more depth than a spec change can. The .github/ directory holds the workflow configuration for the repository.

A few smaller entries are worth noting. Contributing.md is the guidelines file the README refers to. wasm-specs.bib is a bibtex file, and the README gives a specific instruction about it: for citing WebAssembly in LaTeX, use that file. w3c.json is the standard W3C process metadata file used in specification repositories. There is a .gitattributes file, a .gitignore, and a .gitmodules, the last of which means the clone carries submodule references rather than being fully self-contained.

If you are trying to find the proposal, the path is proposals/threads/Overview.md and everything else in this tree is the surrounding specification apparatus.

The readable version lives on GitHub Pages

The README distinguishes between the sources you edit and the document you read. The sources sit in this repository, and a formatted version of the spec with the proposed changes applied is available at webassembly.github.io/threads, which the project listing also gives as the homepage.

That split is the practical workflow for anyone following the proposal. The Markdown and source files under proposals/ and document/ are the working copies, where text gets edited, argued over in review, and occasionally rewritten. The published pages are the rendered result of those changes. The README also notes that the summary of the proposal itself is the overview document, which is the right place to start before reading anything else.

The upstream README, which the proposal README keeps after its own content, describes the same repository pattern for the base specification: a formatted version of that spec is available at webassembly.github.io/spec, and the repository holds the sources for the draft specification, a reference implementation, and the official test suite.

One caveat about reading published spec text. Because the proposal is still in discussion, the text on the pages can change without a version marker, a tag or a release. There are no GitHub releases in this repository. If you need to cite a specific state of the proposal, record the commit you read rather than relying on the published page staying put.

Discussion belongs in the design repository first

The README is unusually explicit about where conversations should happen, and that is a real constraint on how you contribute. It says 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 the spec repository can remain focused. Contributors are also asked to follow the guidelines in Contributing.md.

The split reflects how standards work in practice. A proposal that changes the meaning of existing constructs is a design question, and the design repository is where the arguments about that meaning get settled before anyone bothers to draft spec text. Once the shape is agreed, the change lands here as a document plus interpreter support plus tests.

This is why a pull request here is not the place to propose a new feature. If you want threads to support something it currently excludes, or you want a different memory model, the design repository is where that argument belongs, and the upstream README asks that participation be welcome.

The same directory layout explains the test/ directory's role. In a specification repository, the test suite is the executable form of the argument: it pins down what a conforming implementation must do, and it is what a new proposal change has to extend. The interpreter/ directory plays the same role for the reference behaviour. A proposal that changes semantics has to touch all three of document, interpreter and test, which is exactly why the design discussion comes first.

Citing the spec and reading the licence

Two practical housekeeping items sit in the README. The first is citation: for citing WebAssembly in LaTeX, use the wasm-specs.bib file at the repository root. That is a small convenience with a real use, since a paper, a standards submission or an academic write-up about the threads proposal needs a consistent bibliography entry rather than a hand-typed citation.

The second is licensing, and here the answer is a question rather than a fact. The project listing describes the licence as other, a custom licence that GitHub cannot classify, with a pointer to the LICENSE file at the repository root. There is also a LICENSE entry in the top level listing, alongside LICENSE-related files in the upstream structure. What that means practically is that you cannot rely on a standard SPDX identifier for this repository the way you could for, say, an MIT-licensed package.

That is worth taking seriously if you intend to copy spec text into a derived document, a product specification, or a compliance checklist, because a custom licence may place conditions that a permissive licence would not, and some may attach to redistribution of the text itself. Read the LICENSE file and decide with whoever owns your compliance obligations. This is a note about where to look, not legal advice, and the same caution applies to the upstream specification text that the proposal is built on.

The upstream README also points to the WebAssembly Working Group mailing list, and the topics listed for the repository include a proposal tag, which is how the work is signposted to the wider community.

What this repository will not do for you

Let us be blunt about the limits. There is no released artifact. The repository has no GitHub releases, no version tags to pin, and no build output you can consume as a dependency. If your goal is to run WebAssembly with threads today, this is the wrong place, and the reason is structural: it is a specification working tree, and specifications are not libraries.

There is also a timing dimension. The repository is not archived and the last push was on 2026-07-30, so the text is being worked on. That cuts both ways. The proposal is not frozen, so any statement about what the threads proposal says can move, and the published pages are regenerated as it changes. On the other hand, a repository that receives pushes in July 2026 is not abandoned, and for a proposal that is still in discussion that is the state you would expect it to be in.

The realistic uses are therefore three: reading the proposal text when you need to know what the design currently is, contributing to it if you are implementing an engine, and watching the design repository for the arguments that will determine its final shape. If you are an application team, the better starting point is the overview document, because it is written to be read on its own, and the formatted spec if you need the details.

Editorial conclusion

Adopt this repository if you are writing or reviewing a WebAssembly proposal, or need the exact text of the threads proposal rather than a summary of it. Do not adopt it as a runtime dependency, a compiler target or a library, because it ships no package and no release, and the top level holds a specification working tree. Verify first that proposals/threads/Overview.md reflects the version you are reasoning about, then read the LICENSE file directly, since the licence is a custom one that GitHub cannot classify.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. WebAssembly/threads on GitHub