# WebNN: the W3C proposal for running neural networks in the browser

> The Web Neural Network API is a specification being written by the Web Machine Learning Working Group, and this repository holds its source, its explainers and the build tooling. It is not a library you install, it is the text that will define how a browser exposes a tensor and operator API to JavaScript.

**webmachinelearning/webnn** — 🧠 Web Neural Network API

- Repository: https://github.com/webmachinelearning/webnn
- Website: https://www.w3.org/TR/webnn/
- Stars: 569 · Forks: 72
- Language: Bikeshed
- License: NOASSERTION
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/webmachinelearning-webnn

## A specification, not a library

This repository hosts the Web Neural Network API, which is being worked on in the Web Machine Learning Working Group. The specification itself lives at the W3C technical reports URL, and the working group is where contributions happen. The distinction matters more here than for most projects, because a browser API is a contract rather than a dependency. Nothing in this repository can be installed to run a model; what it produces is a document that browser vendors then implement, or decline to. The repository is a working group space with a licence file, a code of conduct, a contributing guide, a Makefile and a tools directory, and the specification source is the index.bs file. There is also a w3c.json file, which is the standard way a W3C repository declares its group and its licence.

## Explainer documents sit next to the normative source

The repository root carries a set of separate explainer documents, and they are the clearest sign of what the working group is still working out. There is a main explainer, a cache explainer, a device selection explainer, a dynamic shape explainer, a low precision data types explainer and an mltensor explainer, plus a security and privacy document. The names tell you where the specification is unsettled. Device selection is the question of how an application says what it wants, cache behaviour is about how a compiled graph is reused, dynamic shape is about what happens when dimensions change between calls, low precision data types is about the numeric types an implementation must support, and mltensor is the tensor type itself. A security and privacy document alongside them signals that the group is treating the data-handling story as part of the design rather than an afterthought, which for a browser API that takes numeric input from web content is the right thing to worry about.

## The build is a single make target, and Bikeshed can run locally or online

The development section is a short sequence. You clone the repository, install the makefile dependencies with npm install inside the tools directory, and then choose between two ways of running Bikeshed.

```
prompt> git clone https://github.com/webmachinelearning/webnn
prompt> cd tools
prompt> npm install
prompt> cd ..
```

The local route installs Bikeshed on your machine, which works offline and builds faster, and then you run make. The online route uses the Bikeshed HTTP API, which needs internet and is slower, and you run make with the online variable set.

```
prompt> make
```

```
prompt> make online=1
```

In both cases the makefile runs the tools directory to check source formatting and catch common errors, and then uses Bikeshed to convert the index.bs source into an index.html output. If the build is clean you open the generated index.html in a browser to read the result.

## What the Makefile actually does on each path

The makefile is short enough to read as a description of the toolchain. The target is index.html, built from index.bs. Before Bikeshed runs, a Python script called reformat-js.py is executed against the source, which is the formatting and JavaScript checks. In the online branch, the source is posted to the Bikeshed API and the error output is inspected, with a curl and grep combination that fails the build if any line contains ERROR, and a second call with the force flag produces the output file. In the local branch, the commented-out line shows the plain equivalent command, and Bikeshed is invoked with a flag that dies on fatal errors. Either way, a Node lint step runs last with the verbose flag. The clean target simply removes the generated index.html, so a rebuild is always from source.

## How a change becomes a published specification

The pull request process is the part that explains how a document becomes a standard. The contributing guidelines come first, and the specification is written in Bikeshed syntax, so the Bikeshed documentation and the specification's own coding conventions are the reference. To propose a change you are only required to update the index.bs source file, which is a real constraint on the size of a contribution. You are recommended to test your changes locally first so you catch build issues before the review, and if you submit a work in progress pull request that still has errors you are asked to convert it to a draft. As a convention, pull requests are linked to an existing issue for non-editorial changes. After submission, GitHub Actions CI/CD checks for common issues automatically, then group participants review it, and once there is adequate review and approval the pull request is merged and a new version of the specification is deployed to the W3C technical reports URL, with the version history kept separately.

## Conclusion

The webnn repository fits a browser engine implementer, a standards contributor, or a developer who wants to read what the proposed API looks like before it ships. It does not fit an application developer looking for a way to run inference today, because a specification is not an implementation and nothing here can be installed to do that. Verify first that the API you care about is in the current draft, since the proposal is still moving, and read the explainer documents alongside the main specification, because they cover the parts that the normative text assumes you already know.

## FAQ

### What is the Web Neural Network API?

It is a specification being written in the W3C Web Machine Learning Working Group, hosted in this repository. The specification is published at the W3C technical reports URL, and this repository holds its source, the explainer documents and the build tooling, with contributions handled through pull requests reviewed by group participants.

### How do I build the WebNN specification locally?

Clone the repository, run npm install inside the tools directory, then either install Bikeshed locally and run make, which works offline and is faster, or run make with the online variable set to use the Bikeshed HTTP API. The build produces index.html, which you can open in a browser.

### What do I need to change to propose a modification to the spec?

Only the index.bs source file, which is authored in Bikeshed syntax. The contributing guidelines should be read first, along with the Bikeshed documentation and the specification's own coding conventions document, and the local build is recommended before opening a pull request.

### What is in the explainer documents that sit alongside the specification?

Separate explainers cover the cache, device selection, dynamic shape, low precision data types and the mltensor, alongside a main explainer and a security and privacy document, which together mark the areas the working group is still settling.

## Sources

- [Issues](https://github.com/webmachinelearning/webnn/issues)
- [Project website](https://www.w3.org/TR/webnn/)
- [README](https://github.com/webmachinelearning/webnn/blob/main/README.md)
- [webmachinelearning/webnn on GitHub](https://github.com/webmachinelearning/webnn)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/webmachinelearning-webnn