Is WebGPU supported in Chrome, Safari and Firefox?

What the three browsers have enabled

Safari switched it on in one go. The WebKit notes for Safari 26.0 put it plainly: WebGPU "has been enabled in Safari Technology Preview for over a year, and is now shipping in Safari 26.0 for macOS, iOS, iPadOS, and visionOS".

Chrome got there first, but in pieces. According to the implementation status table kept by the WebGPU working group itself, it is on by default on Mac, Windows and ChromeOS since version 113, and on Android since 121 for devices with ARM, Qualcomm or Intel GPUs.

Firefox came last and also in stages: 141 enabled it on Windows, and 147, released on 13 January 2026, states that "WebGPU support is now enabled for devices with Apple Silicon processors on all supported macOS versions".

So the sentence "it is in all three browsers" is true. The problem is the sentence after it.

Where it is still missing

That same working-group table, maintained by the people writing the specification, marks gaps that do not make the headlines:

• Firefox on Linux and Android: enabled in Nightly, not in stable.
• Firefox on Intel Macs: out. Version 147 covers Apple Silicon only.
• Chrome on Linux: Intel Gen12 or newer since 144, and NVIDIA since 147, the latter on Wayland only and with driver 535.183.01 or above.
• Chrome on Windows ARM64: behind the --enable-unsafe-webgpu flag.

None of those gaps is exotic. A studio on Linux, a Mac laptop a few years old or an Android running Firefox are machines that open a client site every day.

Which is why MDN does not call it Baseline

This is the check that settles the argument fastest. The Navigator.gpu page on MDN carries the limited availability badge, with this explanation: "This feature is not Baseline because it does not work in some of the most widely-used browsers".

That badge should not be confused with the annual list. What enters Baseline and Interop each year is a different matter: what MDN is saying here is that WebGPU does not yet meet the bar of working everywhere.

There is also a detail no table shows. navigator.gpu existing does not guarantee a usable GPU: the documentation for requestAdapter() warns that it "will resolve to null if an appropriate adapter is not available". A machine with a blocklisted driver or an old card has the API and no adapter.

What it means for a 3D viewer

It means the fallback is not a concession, it is the real path for part of the audience. And it means writing it before migrating, not after a client reports a black screen.

Three.js provides WebGPU and WebGL paths in the same ecosystem, which can make it easier to share scenes and assets. That does not make migration automatic: materials, effects, performance and supported features need testing in both renderers. You also need an explicit response when no adapter is available: WebGL, a useful alternative view or a clear message.

How to decide it with your own data

Measuring on the client actual phones is still the part nobody publishes, and it is the one that decides whether a scene works: it is covered in the limits of a mobile 3D viewer.

What to ask for before migrating

Three things in writing before anything is touched: the browser and system split of the last few months, which scene will be used as the test, and what happens when there is no adapter. With those, moving to WebGPU is a decision you can defend; without them, it is a blind engine swap, and it shows in the visits that never complain, which is nearly all of them.

To review whether the switch pays off for your viewer, tell us which browsers and machines open it today.