Somewhere between Safari quietly turning WebGPU on by default and caniuse.com ticking past 82% global support, the web platform crossed a threshold that most teams haven't fully priced in yet. WebGPU — the modern browser API that gives web pages direct, lower-level access to GPU hardware — has gone from "experimental feature behind a flag" to "thing you should have an opinion about in your architecture decisions." It's now a W3C candidate recommendation, it ships by default in Chrome, Edge, Safari, and Samsung Internet, and it's quietly becoming the foundation for a category of browser-based applications that simply weren't practical before. The holdout is Firefox, and the reasons why are more interesting than a simple "Mozilla is slow" story.
What WebGPU actually unlocks that WebGL couldn't
To understand why this matters, it helps to be precise about what changed. WebGL, which debuted in 2011, gave web pages a way to talk to the GPU for rendering — it's the technology behind in-browser 3D graphics, data visualizations, and plenty of games for over a decade. But WebGL was built as a graphics API first, adapted from OpenGL ES, and it carries the constraints of that lineage: a rendering-centric model that makes general-purpose computation on the GPU awkward at best.
WebGPU is a different kind of API entirely. It's designed from the ground up to expose two distinct capabilities: modern, more efficient graphics rendering, and general-purpose GPU compute. That second piece is the real story. General-purpose GPU compute means a web page can hand the GPU an arbitrary numerical workload — not just "draw these triangles" but "run this matrix multiplication across thousands of cores in parallel" — and get results back without routing anything through a native application or a plugin.
That distinction is why WebGPU is being described as the most substantial advancement in browser graphics technology since WebGL itself. It's not an incremental improvement to how fast you can render a 3D scene, though it is faster for that too. It's the difference between a browser that can display GPU-accelerated graphics and a browser that can use the GPU as a general compute resource, the same way native applications have for years. In practice, that opens the door to client-side machine learning inference running entirely in a browser tab, more sophisticated real-time rendering for games and visualization tools, and compute-heavy applications — video processing, simulation, procedural generation — that previously required a server round-trip or a desktop install.
The 82% number, and why it's meaningful without being decisive
Per caniuse.com, WebGPU support now sits at roughly 82% of global browser usage. That's a legitimately meaningful milestone — it means the majority of your audience, on a typical consumer-facing site, can run WebGPU-powered features without any fallback logic kicking in. Chrome enabled WebGPU by default starting with version 113 back in April 2023, and that support has carried forward through version 146 and beyond, giving Chrome and Chromium-based browsers (including Edge and Samsung Internet) years of production runway. Safari joined the default-on group with Safari 26 in mid-2025, and Apple didn't stop at baseline parity — Safari's implementation includes HDR image support in the WebGPU Canvas, and as of Safari 26.2, WebXR integration with WebGPU rendering built specifically for Apple Vision Pro.
But 82% is not 100%, and the gap isn't randomly distributed noise — it's concentrated in one specific, well-known browser. That changes how you should think about the number. If Firefox held some small single-digit share of a niche market, treating WebGPU as "basically universal" might be a defensible call. Firefox's actual installed base is large enough that shipping a WebGPU-only experience means deliberately excluding a meaningful, identifiable slice of the web. Anyone making a technical decision here needs to treat 82% as "safe for a primary path with a required fallback," not "safe to ship as the only path."
Why Firefox hasn't shipped it — and why that's not just Mozilla being slow
It's tempting to read Firefox's holdout status as simple lag — a smaller engineering team eventually catching up to where Chromium and WebKit already are. That take undersells what's actually happening. The Firefox team has been explicit about two specific technical objections, and both are legitimate engineering concerns rather than excuses.
The first is fingerprinting risk. WebGPU, by design, exposes detailed information about the underlying GPU hardware — the same access that makes general-purpose compute possible also reveals hardware characteristics that can be used as a tracking signal. A browser that has spent years building its identity around privacy protections has good reason to be cautious about shipping an API whose core value proposition and core privacy risk come from the exact same design decision. You can't have granular hardware access without exposing granular hardware information, and that information is fingerprinting gold for anyone trying to track users across sites without cookies.
The second is driver stability. WebGPU sits closer to the metal than WebGL did, which means it inherits more of the messiness of the underlying graphics driver ecosystem. Chrome and Safari can lean on tightly controlled hardware and driver environments — Apple controls its own silicon and drivers, and Chrome's user base skews toward more predictable, frequently updated driver configurations. Firefox has to support an enormous, long-tail range of GPU hardware and driver versions across Windows, Linux, and beyond, much of it outdated or poorly maintained. Shipping an API that talks more directly to that hardware means shipping more surface area for crashes, rendering corruption, and security bugs that are specific to driver bugs Firefox doesn't control and can't quickly fix.
Put those two together and you get a real, unresolved tension rather than a simple delay: WebGPU's power comes from deeper hardware access, and deeper hardware access is exactly what makes it riskier to ship to an anonymous, adversarial web audience where you can't assume good-faith usage. Chrome and Safari made a call to ship now and mitigate risk with implementation-level protections. Firefox has made a call to hold the line until it's more confident those risks are addressed to its standard. Neither position is unreasonable — it's a genuine tradeoff between capability and caution, and it's worth remembering that browser vendors have disagreed on exactly this kind of tradeoff before, on features ranging from autoplay to third-party cookies.
Evaluating WebGPU for your own roadmap
None of this means WebGPU is unready for production use — it means it's ready for production use within a specific set of engineering guardrails. The right mental model is progressive enhancement: WebGPU as the best available path when the browser supports it, with a deliberate, tested fallback when it doesn't, rather than treating it as a universally available baseline the way you might treat, say, fetch() or CSS Grid at this point.
Feature detection is non-negotiable and it's also simple: check for navigator.gpu before attempting to request an adapter, and branch your rendering or compute path accordingly. Don't infer support from browser or user-agent sniffing — request the adapter directly and handle the failure case, since that's the approach that stays correct as browser support continues to shift under you. For anything rendering-related, WebGL remains a solid, broadly supported fallback that most graphics libraries already abstract behind a common interface, which means the fallback path often costs you a configuration flag rather than a second codebase. For anything that isn't purely visual, canvas 2D or a server-side compute fallback covers you when neither GPU API is available or appropriate.
The products that benefit most from building on WebGPU right now share a common trait: they're either compute-bound or rendering-bound in ways that meaningfully change the user experience when accelerated. Data visualization tools handling large datasets, in-browser machine learning inference (running models client-side instead of round-tripping to a server), games and real-time 3D applications, and video or image processing tools are the clearest wins. If your product is a standard content site, a form-heavy business application, or anything where GPU acceleration wouldn't change the user-facing experience, WebGPU is a solution looking for a problem you don't have yet — and you can safely wait.
Practical takeaways
Start with feature detection on navigator.gpu and build the fallback path first, not as an afterthought — that ordering forces you to confirm the WebGL or canvas 2D experience is actually acceptable on its own, rather than discovering gaps only when a Firefox user files a bug report. Scope your WebGPU investment to workloads where GPU acceleration produces a real, visible difference — data visualization, client-side ML inference, games, and video or image processing — rather than reaching for it as a general-purpose upgrade. Budget for the Firefox gap explicitly in your rollout plan: know what percentage of your actual traffic is Firefox (not the global 82% average, which won't match your audience), and decide up front whether that segment gets a degraded-but-functional experience or the full fallback path. And keep watching Firefox's own signals — fingerprinting mitigations and driver-stability work are active problems, not permanently closed ones, and a shift there would change this calculus again.
WebGPU crossing 82% support is a real milestone, and for the workloads it's built for — GPU compute and demanding real-time rendering — it's the most consequential browser capability to land since WebGL itself. But it arrived unevenly, and that unevenness is the actual engineering problem in front of you: not "should we use WebGPU" but "how do we ship it responsibly to the 18% of the web that can't run it yet." Teams that treat the Firefox gap as a planning input rather than an inconvenience will ship features that work everywhere, just not equally fast everywhere — which is exactly how progressive enhancement is supposed to work.