Eight years of spec work. Endless arguments about shader language design. Countless debates about memory barriers and synchronization. And now, as of November 2025, WebGPU ships by default in Chrome, Firefox, Safari, and Edge.
This is not a drill.
Google announced the milestone on November 25th, marking the moment when the W3C GPU for the Web Working Group's biggest project finally achieved the browser support it needed to become a real deployment target. Chrome has had it since version 113 back in 2023. Safari 26.0 arrived in September. Firefox 141 brought it to Windows users in July.
What Actually Changed
You can now write WebGPU code with reasonable confidence that your users will be able to run it. The API provides direct access to GPU compute and rendering capabilities through an interface designed for modern hardware, not an OpenGL compatibility shim. WGSL, the shader language, is text-based and verifiably safe. No more shipping SPIR-V and hoping for the best.
The compute pipeline is the real story here. WebGPU is not just about prettier triangles. ONNX Runtime and Transformers.js already use WebGPU backends for model inference, which means you can run LLMs in the browser without hitting a server. That was theoretically possible with WebGL compute, but "theoretically possible" and "actually works" are different things.
Babylon.js claims their Snapshot Rendering feature, built on WebGPU's Render Bundles, has already proven major performance improvements by recording and replaying render commands. CPU overhead drops when you stop rebuilding command buffers every frame.
The Coverage Map
Desktop support is solid but not quite universal.
Chrome and Edge deliver WebGPU on Windows via Direct3D 12, on macOS, and on ChromeOS. Android support landed in Chrome 121 for devices running Android 12 or later with Qualcomm or ARM GPUs. Linux is still rolling out. Chrome 144 Beta has it for Intel Gen12+ hardware, with broader support coming.
Firefox 141 covers Windows. Firefox 145 added macOS support for Apple Silicon machines running macOS Tahoe 26. Linux and Android are in progress, with Mozilla expecting to address Android sometime in 2026.
Safari 26.0 ships WebGPU on macOS Tahoe 26, iOS 26, iPadOS 26, and visionOS 26. Apple went all-in, including support for HDR images in WebGPU Canvas and, as of Safari 26.2, WebXR integration with WebGPU rendering on Vision Pro.
For the full breakdown, check the WebGPU Implementation Status page.
Two Engines, One Spec
Under the hood, there are two major WebGPU implementations. Dawn powers Chrome and its derivatives. It is written in C++ and maps to Direct3D 12, Metal, and Vulkan depending on the platform. wgpu powers Firefox. It is written in Rust and targets the same backends through a unified abstraction layer.
Both implementations ship as standalone libraries that work outside the browser. Dawn is a first-class path for native C++ applications. wgpu is widely used in the Rust ecosystem for game engines and graphics tools. Code targeting WebGPU has a clear path from web to native without rewriting your rendering logic.
The two implementations are converging toward a shared C header, webgpu.h, which means cross-platform native apps can target the same API surface whether they build against Dawn or wgpu-native.
Library Support
You do not have to write raw WebGPU to benefit. Three.js has a WebGPU renderer. Babylon.js has extensive WebGPU support. PlayCanvas ships WebGPU apps today. Unity 6 includes WebGPU as a rendering backend. React Native has a WebGPU implementation built on Dawn.
The ML inference story is worth paying attention to. Transformers.js v3 added WebGPU support, which means Hugging Face models run in the browser with GPU acceleration. For applications that care about privacy or offline operation, this matters.
What Is Still Missing
Linux support across all browsers is the obvious gap. Firefox has it in Nightly but not stable. Chrome is phasing it in with driver-specific rollouts. If your users run Linux, you are not quite there yet.
Firefox also notes some performance overhead from their current inter-process communication approach, which they are addressing in subsequent releases. The importExternalTexture method, needed for efficient video processing, is not yet implemented in Firefox's stable builds.
Mobile remains fragmented. Chrome on Android works if your users have recent enough hardware. Firefox on Android is still behind a flag. Safari on iOS 26 is solid, but that requires the latest OS.
Why This Matters Now
WebGL is not going away tomorrow. But WebGL was designed before modern GPUs existed, and it shows. The API assumes an OpenGL-style state machine. It requires expensive translation layers on Metal and Direct3D backends. It lacks compute shaders entirely.
WebGPU was built for hardware that already exists. The execution model maps cleanly to Vulkan, Metal, and D3D12. The shader language was designed from scratch for safety and portability. The API is explicitly asynchronous in ways that WebGL never could be.
For graphics developers, the question has shifted from "should I learn WebGPU" to "when do I ship it."
Links: