WebGPU Shipped in Every Browser. You Can Finally Delete...

The last two posts leaned on a word I kept using without stopping to define it: WebGPU. The built-in Chrome model, the bring-your-own models over WebLLM and Transformers.js, the whole idea that a visitor's own graphics chip can do the math instead of your server, all of it rests on this one browser capability. It is the floor everything else in this series stands on. And in the last several months that floor quietly went from "Chrome only" to "nearly everywhere," which is a bigger deal for a small builder than any single model release.

This is the post about the floor. What WebGPU actually is, why its arrival in every major browser is the moment on-device AI stops being a Chrome party trick, and where the honest gaps still are.

What WebGPU actually is

For years the only way a web page could use a computer's graphics chip was WebGL, an interface built for drawing 3D graphics. You could bend it into doing general math, but it fought you the whole way. WebGPU is the modern replacement, and the important part for us is that it was designed from the start for general-purpose computation on the GPU, not just rendering (web.dev).

That matters because running an AI model is, underneath, a huge pile of the exact kind of parallel math a GPU is built for. WebGPU is the door that lets a web page hand that work to the visitor's graphics chip. No door, no on-device model of any real size. Which is why, until recently, "AI in the browser" and "in Chrome" meant the same thing.

The shift: it is on by default everywhere now

Here is what changed. As of January 2026, WebGPU is what the web platform community calls Baseline, meaning it ships enabled by default across all the major browser engines (web.dev, caniuse):

Chrome and Edge have shipped it on the desktop for a while; they were the early movers.
Safari turned it on by default in Safari 26 across macOS, iOS, and iPadOS, which is the big one, because it brings a huge slice of mobile and Apple-desktop traffic into the fold.
Firefox shipped it by default on Windows and, as of Firefox 145, on Apple-silicon macOS, with Linux and Android still in progress (GPU for the Web implementation status).

Add it up and WebGPU now reaches somewhere in the low-to-mid 80s as a share of global users (caniuse). That is not a niche capability you design around; that is a default you can design on, with a fallback for the rest.

Why this deletes a line item

Think about what a small operator had to do before, if they wanted an on-device AI feature. It ran in Chrome, so they still needed a paid cloud path for every Firefox user, every Safari user, everyone on an iPhone. Which meant the "free, on-device" feature was really "free in Chrome, and metered everywhere else." The server bill never actually went away; it just got smaller.

When the on-device path works in every major browser, that calculus flips. The visitor's own GPU does the work, so:

The inference is free to you across browsers, not just one. The compute is the visitor's, whether they are on Chrome, Safari, or Firefox. The paid fallback shrinks from "most of my traffic" to "the small remainder who genuinely can't run it."
There is no egress and no server in the loop. The data is processed on the device it started on. That is a privacy property you get by architecture, and it holds regardless of which browser the visitor showed up in.
You stop paying for reach. The old reason to keep the cloud path fat was reach. WebGPU being everywhere is exactly what removes that reason.

That is the sentence worth sitting with: the single biggest justification for a large paid inference fallback, "but my non-Chrome users," has mostly evaporated.

The honest gaps

"Mostly" is doing real work in that sentence, so here are the gaps to plan around rather than pretend away.

It is not 100%. Linux on Firefox, older mobile GPUs, and some locked-down or virtualized environments still lack a usable WebGPU adapter. You keep a fallback; you just size it for the remainder instead of the majority.
Present is not the same as capable. A browser can support WebGPU while the actual GPU is too weak or too memory-starved to run the model you had in mind. Detecting support is step one; checking the adapter's limits is step two.
The fallback path still matters. For non-chat work, Transformers.js drops to the CPU through WebAssembly on its own when the GPU is missing, just slower. For a full chat model through WebLLM, no GPU means no local model, so there your fallback is the cloud. Either way, feature-detect first and degrade on purpose.
WebNN is coming underneath it, but it is not here yet. There is a newer standard, WebNN, aimed at the dedicated AI chip (the NPU) in recent laptops and phones for even more efficient inference. It has reached a Candidate Recommendation at the W3C and is available experimentally in Chrome and Edge, but treat it as a bonus when present, not something to depend on (W3C WebNN).

How you actually use it

You almost never call WebGPU directly for AI work; the libraries from the last two posts do that for you. What you do write is the guard: detect the capability, and branch.

// Step 1: is WebGPU even present?
if (!('gpu' in navigator)) {
  useCpuOrCloudFallback();
} else {
  // Step 2: is there a real, usable adapter behind it?
  const adapter = await navigator.gpu.requestAdapter();
  if (!adapter) {
    // API exists but no usable GPU (headless, blocklisted, VM). Fall back.
    useCpuOrCloudFallback();
  } else {
    // Step 3: the adapter's limits tell you how big a model is realistic.
    const maxBuffer = adapter.limits.maxBufferSize;
    const maxBinding = adapter.limits.maxStorageBufferBindingSize;
    // Pick a model tier that fits, then load it via WebLLM or Transformers.js.
    loadOnDeviceModel({ maxBuffer, maxBinding });
  }
}

Those limits are the honest part. A browser saying "yes, I have WebGPU" tells you the door is open; the adapter's maxBufferSize and maxStorageBufferBindingSize tell you how much you can actually fit through it, which is what separates "a 1B model runs fine" from "an 8B model will never load here."

Reading all of that off your own machine by hand is tedious, so I built a tool that does it for you.

Try the WebGPU Capability Reporter — it detects WebGPU in your browser, names your GPU adapter, reads the key limits, estimates which model-size tiers are realistic on your hardware, and checks for WebNN too. It runs entirely in your tab and pairs with the In-Browser LLM Fit Calculator from the last post.

The bottom line

Models get the headlines, but the capability that actually changed the economics is this plumbing layer. WebGPU going from one browser to all of them is what turns "on-device AI" from a demo you show in Chrome into a default you can ship to almost everyone, with the cloud reserved for the shrinking remainder. Build the on-device path as your primary, detect the capability, tier by the adapter's real limits, and keep a fallback sized for the gap rather than the majority. That is the whole move, and the floor is finally solid enough to stand on.

If you are assembling a whole network of sites and tools that lean on capabilities like this instead of a stack of monthly bills, that build-your-own approach is the argument of my book The $100 Network (search the title on Amazon Kindle). The short version lives on this blog, in the posts below.

Fact-check notes and sources

WebGPU is Baseline across major browsers: as of the start of 2026 WebGPU ships on by default in Chrome, Edge, Firefox (Windows and Apple-silicon macOS as of Firefox 145), and Safari 26 (macOS, iOS, iPadOS), with Linux and Android still in progress (web.dev, caniuse, GPUweb implementation status).
WebGPU is designed for general-purpose GPU compute, not only rendering, which is what makes browser-side model inference practical (web.dev).
Global support share: WebGPU coverage sits in the low-to-mid 80s as a percentage of global users in 2026, with the gaps concentrated on Linux Firefox and older mobile GPUs (caniuse).
WebNN status: the Web Neural Network API is a W3C Candidate Recommendation targeting NPU and GPU acceleration, available experimentally in Chromium browsers, and is not yet a stable capability to depend on (W3C WebNN specification).
Adapter limits: navigator.gpu.requestAdapter() returns an adapter whose limits (including maxBufferSize and maxStorageBufferBindingSize) bound how large a model can realistically run (WebGPU specification).

This post is informational, not engineering advice. Mentions of Google, Apple, Mozilla, Microsoft, the W3C, and other third parties are nominative fair use. No affiliation is implied. Browser support and standards status change quickly; verify against the current documentation before you build.

WebGPU Shipped in Every Browser. You Can Finally Delete the Paid AI Fallback.