Last year, when talking to friends about AI inference in the browser, nine out of ten would say "WebGPU can barely run small models." WebNN? What's that — just a W3C Community Group toy.
This year, things have changed.
On January 22, 2026, the W3C published an updated Candidate Recommendation Snapshot of the Web Neural Network API. What does the CR stage mean? The core design of the standard is frozen — no more major changes. The remaining work isn't "what to build," but "who can prove they can build it."
The W3C requires two independent, interoperable browser implementations plus a publicly verifiable test suite before moving to Proposed Recommendation. In other words, WebNN has entered the stage where the exam-setter is asking candidates to hand in their papers.
---
From "Toy" to "Actually Usable": What Was Added in 2025–2026
After going through the Changelog, the six items below are what convinced me WebNN is no longer a placeholder.
Transformer operator support. This is the biggest change. Previously the WebNN operator set was largely stuck in a pre-2019 CV model mindset — convolutions, pooling, fully connected layers: sufficient but not exciting. Now with attention and quantizeLinear/dequantizeLinear added, you can run quantized Transformer models in the browser. Not toy demos — inference that produces meaningful results.
MLTensor API. WebNN and WebGPU can now share buffers without copying data back and forth. This matters more than it sounds — the biggest cost of running models in the browser isn't compute, it's memory movement. If a 7B model's intermediate tensors bounce between the JS heap and GPU buffers a few times, performance collapses. MLTensor opens up that path.
Accelerator selection. You can now explicitly specify the backend: GPU, NPU, or CPU. No more relying on the platform's "best guess." For debugging and performance tuning, this turns a black box into a configurable engine.
Worker support. Inference can now run in Shared Workers and Service Workers. Previously WebNN (and WebGPU) contexts were bound to the main page and lost on navigation. Running in background threads means you can run inference in one tab while browsing normally in another.
Context loss handling. Recovery behavior after GPU/NPU crashes is now clearly defined. This isn't a performance feature — it's a marker of engineering maturity. An API only becomes serious at the stage where "we have to think about what happens when things fail."
Operator labels. Diagnostic labels for operators to ease debugging. A small feature, but it shows the API designers are starting to consider developer experience.
---
On the Browser Side: Chrome Leads, Others Are Still Warming Up
The real-world rollout looks like this:
Chrome / Edge: most complete implementations, passing many WPT (Web Platform Tests). The Chromium team's investment in WebNN is serious — consistent with their WebGPU strategy: master the standard, get tests passing, then ship to users.
Backend coverage is decent too: DirectML on Windows, CoreML on macOS/iOS, NNAPI on Android, and OpenVINO on Intel platforms. Mainstream hardware is basically covered.
Safari / Firefox: slow to follow. Not news. Apple has always been conservative about web standards — WebGPU took a long time too. The Firefox team has limited resources and can't prioritize this. Frankly, don't expect cross-browser consistency in the short term.
What does this mean in practice? If your target users are Chrome users (in China, many people only use Chrome or Chromium-based browsers), you can start experimenting now. If you need a cross-browser product, keep waiting.
---
What You Can Do Now
WebNN's current capabilities have passed the "proof of concept" stage:
- Running Stable Diffusion in the browser. Not the unusably slow kind — it can genuinely produce decent images.
- Local Transformer inference. DistilBERT and small LLMs are fine. I've tried several demos; latency is acceptable.
- Real-time video analysis and speech-to-text. These always needed hardware acceleration, and WebNN provides a more specialized path than WebGPU.
- WebGPU as fallback. Automatically degrading to WebGPU when WebNN is unavailable is a low-risk progressive enhancement strategy for developers.
---
When Is It "Truly Usable"?
This question needs two layers of answer.
Standards-wise, it's mature. The core design is frozen; no major changes coming. Vendor implementations and interop testing are the current main storyline.
Ecosystem-wise, not yet. The model conversion toolchain (ONNX → WebNN) is still maturing. Getting a PyTorch model into the browser involves ONNX export → operator compatibility checks → WebNN format conversion, with pitfalls at every step. The memory and performance bottlenecks of large models (7B+) in-browser remain unsolved — that's not an API problem, it's the browser sandbox's own memory limits.
Safari and Firefox's lag means that if you need a cross-browser-consistent product, now is not the time.
My judgment: WebNN will reach "production-ready" levels from late 2026 to early 2027 — provided Chrome maintains its current pace and at least one more browser vendor (most likely Firefox; I don't hold much hope for Safari) catches up.
---
A More Interesting Question
The most interesting part of all this isn't WebNN itself, but that the addition of Transformer operators makes it genuinely useful for LLM inference for the first time.
This means the browser is evolving from a "rendering engine" into an "AI runtime." When we said "the browser is the new operating system," it was mostly a metaphor. Now the combination of WebGPU + WebAssembly + WebNN makes that metaphor feel less and less like a metaphor.
If this trend holds, in a year or two frontend engineers will need to care about not just DOM and CSS, but quantization precision, KV Cache, and context windows. Will this transition happen? I don't know. But this direction is worth watching.
---
*Posted by "Buzi-ge", June 2026, Shanghai*