Skip to content
RU

WebGPU in 2026: browser support against real-world use

TL;DR. WebGPU is fully supported by browsers accounting for 83.99% of global page views.

WebGPU is fully supported by browsers accounting for 83.99% of global page views. Meanwhile 0.004% of Chrome page loads actually submit work to a graphics processor.

The gap between "can" and "does" is roughly twenty-one thousand times. Below: both figures with their denominators, exact ship dates per browser, the Safari restriction absent from Apple’s documentation, and one anomaly in Chrome’s counters that we declined to present as growth.

Support is nearly everywhere

Per caniuse as of 24 August 2026, WebGPU is fully supported by browsers accounting for 83.99% of global page views, with a further 2.95% partial.

But that figure is built unexpectedly. Two thirds of it — 46.3 points of 84 — comes from Chrome for Android alone. Desktop Chrome adds 20.0, Safari on iOS 10.1, Edge 5.1. Neither Firefox nor desktop Safari contributes a single point of full support — both count as partial.

BrowserSince versionContribution to 83.99%
Chrome for Android15146.3
Chrome desktop113 (May 2023)20.0
Safari on iOS26.0 (September 2025)10.1
Edge1135.1
Safari desktop26.0 — partialpartial, 1.57
Firefox desktop141 — partialpartial, 1.38

What the figure is not: it is a traffic-weighted share of page views, not a count of sites, devices or people. And it says nothing about whether real hardware will hand over a graphics adapter — Chrome on Linux and Firefox on Intel Macs count as supporting by version while failing on many actual machines.

Ship dates, and what Apple’s documentation leaves out

Chrome: version 113 (2 May 2023) — ChromeOS, macOS, Windows; 121 (23 January 2024) — Android 12+ on Qualcomm and ARM GPUs; 144 (13 January 2026) — the start of the Linux rollout, so far Intel Gen12+ only.

Firefox: 141 (22 July 2025) — Windows only; 147 (13 January 2026) — all macOS versions on Apple Silicon. Linux and Intel Macs still have no WebGPU by default.

Safari: 26.0, announced by WebKit on 15 September 2025 — macOS, iOS, iPadOS, visionOS.

And here there is a discrepancy worth knowing. Apple’s Safari 26.0 release notes simply say "Added support for WebGPU", with no qualification. But WebKit’s own bug tracker carries reports (299237 and 299510) showing that on macOS 15 with Safari 26 the feature is marked as a preview and switched off — it works from macOS 26. The restriction is real, and Apple’s documentation does not mention it, which is precisely why desktop Safari is listed as partial in caniuse.

Separately: caniuse’s Firefox note is roughly seven months out of date — it still describes a macOS Tahoe restriction that Firefox 147 removed on 13 January 2026. Even reference works go stale, and this is worth checking against release notes.

Sites that actually compute on the GPU: four in a hundred thousand

Chrome publishes use counters — the share of page loads on which a feature was called at least once. As of 25 August 2026:

CounterShare of Chrome page loadsMeaning
WebGPUQueueSubmit0.003967%work actually submitted to the GPU
HTMLCanvasElement_WebGPU0.003759%drawing context requested
WebGPU (adapter request)0.109415%including bare capability probes

The first is the one to count by: adapter requests are also made by code that merely checks whether a GPU exists and then computes nothing on it.

So: browsers can do WebGPU across 84% of page views, while 0.004% of page loads do GPU work. A gap of roughly 21,000×. The two figures have different denominators — caniuse weights all browsers’ traffic, the counter measures Chrome page loads — so read it as an order of magnitude rather than an exact ratio. But the order of magnitude is the point.

The growth is real, though: 0.000003% in August 2023, 0.000339% in 2024, 0.000550% in 2025 and 0.003967% now — roughly sevenfold in a year. The base is simply near zero, and WebGPU has been available in Chrome for three years and four months.

A caveat on the adapter-request counter. Between 19 and 21 August 2026 it jumped from 0.021% to 0.096% — four and a half times in two days — while the counter for actual GPU work did not move at all. Something began probing for an adapter en masse without doing anything with it; no explanation appears in the Chromium notes. The honest comparable baseline before the jump is about 0.021%.

What could not be measured

Nobody publishes a count of sites using WebGPU. The word "WebGPU" does not appear once in the Web Almanac — not in the platform capabilities chapter, not anywhere; HTTP Archive’s public report index carries no such metric. It could technically be computed from their BigQuery extract, but no published figure exists. Chrome’s counter is the only available measurement of real use.

And a reminder on dates: there is no 2026 edition of the Web Almanac; the latest is 2025, whose data is the July 2025 crawl.

The practical consequence for a developer: capability detection is mandatory, and what you must test is not the presence of navigator.gpu but a successful adapter request — because the object exists on machines whose hardware will not hand one over. A WebGL fallback is not a contingency but the primary path for a good half of the desktop audience.

Sources: caniuse, Chrome Platform Status counters, Chrome 144 notes, WebKit on Safari 26.0.

Frequently Asked Questions

What blocks 100 % adoption?

Legacy Android (< 7.0), corporate Chrome with hardware acceleration disabled, low-tier GPUs without Vulkan/Metal/D3D12.

Performance vs WebGL?

Compute-heavy tasks (ML inference, physics): WebGPU is 3-10× faster. Pure 2D graphics: roughly equal.

Is it a standard?

W3C Recommendation finalized August 2023. Future extensions (subgroups, ray tracing) in development.

Try the live tool that powered this guide

Free plan — 10 monitors, checks every 5 min, no card required. Upgrade for 1-minute interval and multi-region monitoring.