For the past several years, the standard architecture for AI-powered web features looked the same: the browser sends data to a server, the server runs an inference call against a hosted model, the server sends results back. The user waits. You pay for compute. The model's weights live on someone else's machine.
That architecture is now optional. WebGPU — the modern replacement for WebGL that shipped in all major browsers through 2023 and 2024 — gives JavaScript direct, high-performance access to the GPU on the user's own device. Libraries like Transformers.js, MediaPipe, and ONNX Runtime Web have caught up to the hardware. In 2026, you can run a real text-generation model, an image classifier, a speech recognizer, or a semantic search engine entirely in a browser tab. No server. No API key. No round-trip latency. The weights download once, get cached, and execute at GPU speed from that point on.
This post explains how WebGPU enables this, what the practical constraints are, and what you can realistically build today.
What WebGPU Actually Is
WebGPU is a low-level browser API for GPU programming. It is not a 3D graphics library — it is a compute platform that happens to also support rendering. The API exposes compute shaders: arbitrary programs that run in parallel across thousands of GPU cores. Matrix multiplication — the dominant operation in neural network inference — maps onto this model almost perfectly.
The predecessor, WebGL, was designed purely for graphics. Developers hacked it into doing compute by encoding data as textures and running fragment shaders against them. It worked but was slow, unpredictable, and limited to 32-bit floats in awkward formats. WebGPU was designed from the start to support compute workloads. It supports 16-bit floats (f16), storage buffers, asynchronous GPU commands, and pipeline caching — all the primitives you need to run neural network inference efficiently.
Browser support reached a stable baseline in 2024: Chrome 113+, Edge 113+, Safari 18+, and Firefox 141+ all ship WebGPU. Today, WebGPU is available to over 90% of active browser sessions globally.
The Stack: How Models Get Into the Browser
You don't write WebGPU shaders by hand to run a language model. You use a library that handles the heavy lifting. The three most important libraries in this space are:
- Transformers.js (Hugging Face) — a JavaScript port of the Python Transformers library. It supports hundreds of model architectures from the Hugging Face Hub, uses ONNX Runtime Web under the hood, and automatically selects WebGPU, WASM, or CPU execution based on browser capabilities. The API is intentionally close to the Python original, so Python ML developers can read it without friction.
- ONNX Runtime Web (Microsoft) — a general-purpose inference engine for ONNX-format models. It's what Transformers.js builds on, but you can use it directly if you have your own ONNX models or need tighter control over execution providers and session options.
- MediaPipe (Google) — a collection of pre-built, optimized ML pipelines for vision tasks: face detection, hand tracking, image segmentation, object detection, image embedding. It abstracts away model loading entirely and gives you task-level APIs rather than raw tensor operations.
Models are distributed in ONNX or GGUF format and hosted on the Hugging Face Hub or a CDN. On first use, the browser downloads the weights and caches them in the Cache API or IndexedDB. Subsequent loads are instant.
What You Can Run Today
The practical constraint is model size. Large models (70B parameters, multi-gigabyte weights) are not feasible in a browser — they don't fit in GPU VRAM on most consumer devices. But the class of models that do fit is surprisingly capable:
- Text generation: Phi-3.5 Mini (3.8B), SmolLM2 (1.7B), Gemma 2B, Qwen2.5 0.5B. These run in the browser with WebGPU and produce coherent, useful text at 20–60 tokens per second on a mid-range GPU. Phi-3.5 Mini in particular punches well above its weight on reasoning and code tasks.
- Embeddings and semantic search: Models like
all-MiniLM-L6-v2(22M parameters) are tiny and extremely fast. Running a semantic search engine over a local document collection in the browser is a weekend project now. - Image classification and object detection: MobileNet, EfficientDet, and YOLO variants have run in browsers for years. With WebGPU they're significantly faster and can process video frames in real time without dropping frames.
- Speech recognition: OpenAI Whisper's smaller variants (Whisper Tiny, Whisper Base) run in the browser with Transformers.js. Real-time transcription from the microphone is feasible on most laptops.
- Image generation: Stable Diffusion 1.5 and SDXL-Turbo have been demonstrated in-browser using WebGPU. Generation times are long (10–60 seconds depending on device) but the inference is local and private.
A Minimal Example: Sentiment Analysis in the Browser
Here's what using Transformers.js actually looks like. This runs a sentiment classifier entirely client-side with WebGPU acceleration:
import { pipeline, env } from "@xenova/transformers";
// Prefer WebGPU; fall back to WASM if unavailable
env.backends.onnx.wasm.proxy = false;
const classifier = await pipeline(
"sentiment-analysis",
"Xenova/distilbert-base-uncased-finetuned-sst-2-english",
{ device: "webgpu" }
);
const result = await classifier("WebGPU makes browser AI feel real.");
console.log(result);
// [{ label: 'POSITIVE', score: 0.9998 }]
The first call downloads the model weights (~67 MB for this model), caches them, compiles the WebGPU shaders, and runs inference. Subsequent calls on the same page or future visits use the cache and skip the download. The entire classification takes a few milliseconds on GPU after warmup.
There's no server. The weights transfer from a CDN directly to the browser. The inference runs on the user's GPU. Nothing is sent to your backend.
The Privacy Angle
In-browser inference is private by construction. When a user types a query into a search box powered by a local embedding model, that query never leaves their device. When a user runs Whisper in the browser to transcribe a meeting recording, the audio never touches a server.
This matters in two contexts. First, regulated industries: healthcare, legal, and financial applications where user data cannot leave a device or jurisdiction without explicit consent now have a path to AI features without the compliance headache of sending data to an external inference API. Second, privacy-sensitive consumer applications: users are increasingly wary of where their data goes. "Runs entirely in your browser, we never see your data" is a genuine differentiator that in-browser AI makes possible to promise and keep.
The Constraints You Can't Ignore
In-browser AI is real and useful, but it comes with real constraints:
- First-load cost: Downloading model weights on first use can be 50 MB to 1.5 GB depending on the model. You need a loading state, a progress indicator, and a plan for users on slow connections. Models are cached after the first load, but the first experience matters.
- Memory pressure: Mobile devices have limited VRAM and shared GPU/CPU memory. A model that runs fine on a laptop might crash a tab on a phone. Always test on low-end hardware and provide a graceful fallback.
- Shader compilation: WebGPU compiles shaders at runtime. On first use there's a noticeable pause (often 1–5 seconds) while the browser compiles the compute kernels. You can mitigate this with pipeline caching, but you can't eliminate it entirely on first run.
- No persistent background execution: Browser tabs can be throttled or suspended. Long-running inference in a background tab may be paused by the browser. For tasks that need to run continuously, a Service Worker or a dedicated tab is required.
- Model capability ceiling: A Phi-3.5 Mini is genuinely good, but it is not GPT-4o. For tasks that require deep reasoning, large context windows, or broad world knowledge, a hosted API is still the right tool. In-browser AI fills a specific niche; it does not replace cloud inference.
Where This Is Going
The capability boundary is moving fast. Two trends are compressing the gap between "what fits in a browser" and "what's actually useful":
First, model compression. Quantization techniques — reducing weights from 32-bit to 8-bit, 4-bit, or even 2-bit representations — have dramatically shrunk model sizes without proportional quality loss. A 4-bit quantized Phi-3.5 Mini weighs about 2 GB and runs on integrated graphics. A year ago that combination would have seemed implausible.
Second, hardware improvements. Every new generation of Apple Silicon, Qualcomm Snapdragon, and AMD RDNA chips ships with more dedicated neural engine capacity. The hardware your users already own is getting significantly better at inference every year. The "what can run in a browser" ceiling rises with every new device cycle.
The combination means that the class of tasks suitable for in-browser inference will keep expanding. Today it's sentiment analysis, semantic search, and real-time speech transcription. In two years it will include tasks that today seem like they require a datacenter.
Building Something Today
The fastest path to shipping something real with WebGPU AI is Transformers.js. The documentation is good, the Hugging Face Hub has thousands of ONNX-compatible models, and the community is active. Useful starting points:
- The Transformers.js documentation includes a getting-started guide and task-specific examples for classification, generation, transcription, and more.
- The Transformers.js examples repository has complete working demos: a real-time Whisper transcription app, a semantic image search engine, an in-browser code completion tool.
- For vision tasks, MediaPipe Studio lets you prototype task pipelines interactively before writing any code.
If you want to understand how WebGPU compute shaders work at a lower level, the Chrome WebGPU documentation is comprehensive, and the WebGPU Fundamentals site walks through compute pipeline construction from scratch.
The browser is no longer just a display layer for AI results computed elsewhere. It is an inference runtime. That shift is quiet — it doesn't make headlines the way a new foundation model does — but for developers building applications where latency, privacy, or cost matter, it's one of the most practically useful things to happen to the web platform in years.