WebGPU Just Hit Baseline in Every Major Browser. Three.js Is Already Shipping It and WebXR Is the Real Winner.

If you build anything for the web 3D stack, this is the news you have been waiting for. As of January, WebGPU is officially Baseline. That means every major browser, Chrome, Edge, Firefox on Windows and macOS, and Safari 26 on iOS and macOS Tahoe, ships it stable and on by default. No flags, no opt-in, no platform-specific polyfill. The 15 year run of WebGL as the de facto web 3D API is over.

And the most interesting downstream story is not desktop graphics. It is WebXR. Browser-based VR and AR has spent years fighting the perception that it could not match native performance. WebGPU is the answer to that argument, and it just landed everywhere at once.

Three.js made it boring (in the best way)

The pivotal moment for adoption was Three.js r171, which shipped back in September. With r171, you can swap WebGLRenderer for WebGPURenderer with a one line change. The library handles the fallback to WebGL 2 automatically if a user is on an older browser. There is no API to learn. There is no port. You just import the new renderer and ship.

That is rare in graphics. Most major API transitions, OpenGL to Vulkan, DirectX 11 to DirectX 12, are multi-year ports that require rewriting renderers from scratch. Three.js abstracted enough of the underlying graphics layer that the migration cost dropped to almost zero for the 2.7 million developers a week pulling it from npm. Babylon.js, which has been WebGPU-first since version 5.0 in 2022, is the same story.

The result is that the network effect is happening fast. Studios that ship WebXR experiences in Three.js or Babylon.js are flipping the switch on WebGPU and seeing big perf wins, often without touching anything else in their codebase.

Why WebXR cared so much about this

WebXR has been bottlenecked by WebGL for a long time. WebGL is fundamentally a 2010-era API. It assumes a single render thread, it has limited support for compute shaders, and the JavaScript-to-GPU communication overhead is heavy. None of that is great when you are trying to render two camera views at 90 frames per second on a mobile chip strapped to someone's face.

WebGPU fixes most of those problems. It supports compute shaders natively, which means GPU-driven culling, particle systems, and physics simulations actually become viable in the browser. It has a much lower JavaScript driver overhead, which matters enormously on Quest where every millisecond of CPU time is contested. And it exposes modern features like multi-view rendering directly, which is the optimization you need for stereoscopic VR rendering to be efficient.

Meta Quest Browser, Samsung Internet, and Safari on Vision Pro all expose WebXR through the same WebGPU pipeline now. That is the consolidation that immersive web devs have been waiting for. Write once, hit every major XR runtime, with native-class graphics performance. That has not been a true statement until 2026.

The numbers are starting to follow

The 2025 Web Almanac put WebGPU adoption at 65 percent of new web apps that ship 3D content. That number was around 8 percent two years ago. WebGPU.com tracks production-grade case studies that are quietly piling up: Nexara Labs cited a 40 percent conversion lift on a WebGPU-rendered product configurator, ChartGPU is rendering a million data points at 60 frames per second in the browser, and a dozen retail AR try-on experiences are running at framerates that would have been impossible on WebGL last year.

For WebXR specifically, the Interop 2026 initiative includes WebXR as a focus area, which is the W3C process by which browser vendors agree to close the gaps between their WebXR implementations. That work is happening on the WebGPU foundation, not WebGL. The implication is that anything new shipping in the standard from now on assumes a WebGPU rendering path.

What this means if you are a dev

If you have an existing Three.js or Babylon.js project, just flip the renderer. Run your perf tests, see what improves, ship it. The fallback to WebGL 2 is automatic so you are not breaking anything for users on older browsers.

If you are starting something new, write WGSL shaders, not GLSL. Use compute pipelines for anything you would have done on the CPU two years ago. Treat WebGL like a legacy fallback target instead of the primary API. The next decade of web 3D and web XR is going to be written on top of this.

WebGPU did not arrive with the same fanfare as WebGL did fifteen years ago, but it might end up being the more important release. The browser is now a real graphics platform.