Can your browser run a local AI model?

Run the check to populate this.

What this page checks — and what no browser will tell it

Browsers deliberately refuse to expose your hardware. There is no way for a web page to read your VRAM, your CPU model, your clock speed or your disk size, and navigator.deviceMemory is quantised and capped at 8 GB, so a 64 GB workstation reports 8. What a page can do is check capability flags, read a few coarse buckets, and measure performance directly. This check does all three:

• A real graphics adapter, or a fake one. Asking for WebGPU is not enough — a browser can report support and hand back a software renderer, which is slower than the CPU path it would otherwise take. The check asks for the high-performance adapter and looks at whether it is a fallback.
• Which runtime build applies. The local model runtime is llama.cpp compiled to WebAssembly. With JavaScript Promise Integration and Memory64 it uses the fast build and can address models above 4 GB; without them it falls back to a compatibility build that works but is slower and capped.
• The storage quota, not your disk. A model is downloaded once and kept in the browser's cache. The binding limit is the quota the browser grants a site — roughly 60% of free disk in Chromium, considerably less in Safari — so this is what decides whether a 5 GB model can be kept at all.
• Actual memory bandwidth. A short compute shader streams a large buffer through the GPU and times it. That separates a real graphics card from a weak integrated one by an order of magnitude — a measurement, not a spec sheet.

What actually decides speed in a browser (we measured it)

The textbook rule for local language models is that generating one token at a time is limited by memory bandwidth, because every token re-reads the model's weights — so tokens per second should be roughly your GPU's bandwidth divided by the model's size, and a bigger model should be proportionally slower.

We built that rule into this page, then measured it, and on this stack it does not hold. Three models on one RTX 4090, in Chrome, three generation passes each:

Model	File size	Measured	The rule predicts
Qwen3 0.6B	0.4 GB	48.8 tok/s	—
Qwen3 1.7B	1.1 GB	46.6 tok/s	17.7 tok/s
Qwen3 4B	2.6 GB	58.6 tok/s	7.5 tok/s

A 6.5× range of model sizes, and the largest model was the fastest. The reason is that a language model running in a browser tab pays a large fixed cost per token — crossing the JavaScript/WebAssembly boundary, dispatching each layer to the GPU separately — and in the size range a browser can actually handle, that cost dominates. The GPU spends much of each token waiting to be told what to do next. Bandwidth is the ceiling; this runtime is nowhere near it.

For context: the bandwidth figure above is a real reading. On the same 4090 it measures around 920 GB/s, about 91% of that card's theoretical 1008 GB/s, so the benchmark is working correctly — it is the extrapolation from it to a per-model speed that the evidence does not support.

Browser support

Browser	Platform	WebGPU	What to expect
Chrome / Edge 113+	Windows, macOS, Linux, ChromeOS	Yes	Best supported. Full-speed GPU path and the fast runtime build.
Safari 26+	macOS, iPadOS	Yes	Works on Apple Silicon. Browser storage limits are tighter, so large models may not cache.
Firefox 141+	Windows	Yes	Works. Falls back to the compatibility runtime build where JSPI is missing, which is slower.
Older or mobile browsers	Any	No	Cloud providers (OpenAI, Anthropic) still work; on-device models do not.

Phones and tablets are out of scope by design. A local model needs several gigabytes of memory and sustained power draw; the honest answer on a phone is to use a cloud provider.

If the check says no

You still have three options, in order of least effort:

Frequently asked

Related