WebGPU Landed in Every Browser. A Casual Catalogue Is Right to Ignore It.

WebGPU now ships in Chrome, Safari and Firefox. A licensed casual games catalogue still has almost no reason to render with it, and the reach math says so.

The announcements landed through 2025 and 2026 and they all said roughly the same thing: WebGPU is here, it is in every major browser, the web finally has a modern graphics API. That is true. It is also the least useful sentence you could carry into a decision about what your portal runs.

Because "supported in every major browser" and "safe to render your catalogue with" are separated by about four layers of gating that nobody puts in the headline — operating system floors, GPU vendor allowlists, and an engine ecosystem that quietly did not follow. If you licence games rather than write them, this matters in a specific and boring way: it decides whether a build you paid for runs on the devices your traffic actually arrives on.

🧩 "All Major Browsers" Is Four Different Shipping Stories

The W3C GPU for the Web working group maintains an Implementation Status wiki, and it is the only version of this story worth reading, because it breaks support down by platform and GPU vendor instead of by browser name. Here is what it currently records:

• Chrome desktop — shipping since version 113 on Windows (x86/x64), macOS and ChromeOS. Windows on ARM64 is still behind a flag.
• Chrome on Linux — Intel Gen12+ since version 144, NVIDIA on Wayland since 147, and everything else still requires command-line flags.
• Chrome on Android — shipping since version 121, but only on Android 12 or later, and only on ARM, Qualcomm and Intel GPUs. Imagination GPUs arrived at version 139 on Android 16+.
• Firefox — Windows since 141, macOS since 147. Linux and Android are still Nightly-only, with Mozilla expecting to ship during 2026.
• Safari — version 26, across macOS Tahoe 26, iOS 26, iPadOS 26 and visionOS 26.

Read that list again and notice what kind of gate each one is. Chrome desktop is a browser-version gate, which resolves itself in weeks because Chrome auto-updates. Safari is an operating system gate. Chrome on Android is an operating system gate and a GPU vendor gate. Those two do not resolve themselves, and they do not resolve on the same timeline as anything you control.

The Samsung line is the one to look at

Buried in the same wiki is a row for Samsung's Xclipse GPUs — the ones in Exynos-powered Galaxy handsets — marked "probably 154." Chrome for Android is at 151. So on a meaningful slice of Samsung's fleet, Chrome does not turn WebGPU on today, and the working group's own estimate for when it will is a few releases out and hedged with the word "probably."

StatCounter put Samsung at 19.13% of worldwide mobile vendor share in July 2026, second only to Apple at 31.59%. Not all of those are Exynos parts — Samsung ships Snapdragon variants in many regions, and those use Qualcomm's Adreno, which is supported. But if your traffic skews to the regions where Exynos is the default configuration, you are looking at a WebGPU hole in your single largest Android vendor that no amount of browser updating closes.

📐 85% Is a Ceiling, Not a Floor

Can I Use currently reports WebGPU at 83.99% full support plus 1.57% partial, for 85.56% global. That is the number people quote, and it is a fine number as far as it goes. Two things about it are worth knowing before you build on it.

First, Can I Use lists Firefox as having the feature disabled by default across current versions, which contradicts the gpuweb wiki's record of Firefox 141 shipping on Windows and 147 on macOS. Both sources are credible; they disagree because per-platform partial rollouts are genuinely hard to compress into a single support cell. When two good sources disagree, take the range and plan against the pessimistic end. Nobody has ever regretted that.

Second, and more importantly: that 85% is not distributed the way browser-support percentages usually are. Normally the unsupported tail is stale browsers, and it shrinks on its own. Here, most of the tail is hardware and OS.

On iOS the renderer is welded to the OS version

Safari 26 is the WebGPU release, and on iPhone you cannot have Safari 26 without iOS 26. Apple published adoption figures based on App Store transactions on 7 June 2026: 79% of all iPhones were running iOS 26, and 86% of iPhones introduced in the last four years. Apple's own comparison to the year before is instructive — iOS 18 was at 82% and 88% on the equivalent date in 2025, so iOS 26 is tracking slightly behind its predecessor, not ahead.

Then there is the hardware floor. iOS 26 dropped the iPhone XS, XS Max and XR — the A12 generation, shipped in autumn 2018. Those devices are stuck on iOS 18 permanently and will never receive WebGPU. They are not old enough to have left the installed base, and in the price-sensitive markets where a licensed casual catalogue often does its best numbers, five-to-eight-year-old iPhones are not an edge case. They are a segment.

On Android it is the OS version and the silicon

StatCounter's July 2026 Android version share lists Android 16 at 25.49%, Android 15 at 17.19%, Android 13 at 14.78%, Android 14 at 13.14%, Android 12 at 10.09% and Android 11 at 8.32%. Those six add to roughly 89%, which means about a tenth of Android sessions sit in a tail StatCounter does not break out — versions older than 11, plus whatever it cannot classify.

Chrome's WebGPU floor is Android 12. So Android 11 alone accounts for 8.32% of Android sessions that are out on OS grounds before you get anywhere near a GPU allowlist, and everything below it is out too. Stack the vendor gating on top and the practical Android reach is visibly below the global headline figure.

🎮 The 2D Stack Did Not Follow

Here is the part that should settle the argument for anyone running an arcade catalogue rather than a showcase demo: the engines that casual web games are actually built in have not moved.

Phaser 4 shipped in April 2026 with a completely rewritten renderer, and the headline claim is a good one — over a million animated sprites in a single draw call, up to 100 times faster than before. Phaser's own Phaser 4 page does not mention WebGPU anywhere. The rewrite is a WebGL renderer. In November 2025, Phaser's news feed carried a post about a studio that forked Phaser 4.0 specifically to add full WebGL 2.0 support for their project. That is the state of the most widely used 2D HTML5 framework in the world: a fresh 2026 renderer that is not on WebGPU, and where full WebGL 2.0 was recent enough to be someone's fork.

Unity is blunter about it. Unity's manual for the 6000.3 release states plainly that "WebGPU is experimental and not supported by all browsers and devices," and WebGL2 remains the default graphics API for Web builds. You will find blog posts asserting that Unity ships WebGPU as the default web target. Unity's own documentation says otherwise. Believe the documentation.

This is not engine vendors being slow. It is engine vendors being correct about their workload. A match-3, a solitaire, a runner, a bubble shooter — these are a few hundred sprites, alpha blending, and a tilemap. They are not draw-call bound and they are not compute bound. WebGPU's advantages are lower CPU overhead per draw call and access to compute shaders. If you are not issuing thousands of draw calls and you have no compute work, the API gives you a rewrite and a compatibility problem in exchange for a frame time you were already hitting.

🔍 A Statistic Going Around That Is Not in the Source It Cites

While researching this I kept hitting a claim, repeated across several sites, that the 2025 Web Almanac puts WebGPU adoption at 65% of new web apps shipping 3D content. It is a tidy number and it gets cited confidently.

It is not in the Web Almanac. I read the 2025 WebAssembly chapter, which is where a claim like that would live, and the chapter does not discuss WebGPU at all. What it does contain is a useful reality check on how quickly advanced web platform technology actually diffuses: WebAssembly, an eight-year-old shipped standard, appears on 0.35% of desktop sites and 0.28% of mobile sites — around 43,000 sites total. Nearly 80% of WebAssembly requests trace back to Microsoft's .NET and Blazor. The largest binaries the chapter measures top out around 381 KB at the 90th percentile.

The point is not that the Almanac is bearish on new tech. The point is that when someone quotes you an adoption number for a graphics API, ask which document it came from and then open the document. In this case the trail dead-ends. If you are doing due diligence on a source-code purchase and the seller's technical pitch leans on figures like that one, you have learned something about the seller.

⚡ Where WebGPU Genuinely Wins

None of this is an argument that the API is pointless. It is an argument about matching the tool to the catalogue. WebGPU earns its keep when:

• You are draw-call bound. Large 3D scenes with thousands of distinct objects are exactly the case WebGPU's lower per-draw CPU cost was designed for.
• You need compute shaders. GPU particles, GPU physics, and on-device inference have no good WebGL equivalent. This is the real unlock, and it is not a rendering feature.
• Your audience is desktop and self-selecting. A Steam-adjacent web demo, a WebXR experience, an internal tool — narrow, recent, controllable hardware.

Look at that list and then look at your catalogue. If you licence a thousand casual titles for a portal, a telecom deck or a white-label site, essentially none of them are in any of those three categories. The overlap between "games that benefit from WebGPU" and "games that a broad licensed catalogue consists of" is close to empty.

🧾 Two Render Paths Is a QA Line Item, Not a Flag

The standard advice is progressive enhancement: WebGPU where available, WebGL2 fallback everywhere else. As engineering guidance it is correct. As an operating commitment it is chronically under-priced, and the cost lands on whoever runs the portal rather than whoever wrote the game.

Two render paths means every title is two titles for testing purposes. It means visual differences — text rendering, particle behaviour, transparency and blend modes are the classic divergence points — that show up as player complaints on one device family and not another. It means when something breaks, your first diagnostic question is which path the player was on, and you probably are not logging that. It means a driver-level blocklist change in a Chrome release can silently flip a chunk of your audience from one path to the other between Tuesday and Wednesday.

For a studio shipping one flagship title, that is a reasonable trade for a real performance win. For an operator running hundreds of licensed HTML5 games with a small team, it is a permanent tax collected against a benefit your genre does not receive. Say no to it deliberately, in writing, rather than inheriting it because a build happened to arrive with a WebGPU path enabled.

✅ What to Ask Before You Licence a Build

Concretely, when a title comes across your desk:

1. Which renderer does it initialise, and what happens when that fails? "It falls back" is not an answer. Ask what the player sees during the fallback — a black frame, a reload, a silent downgrade — and test it with WebGPU disabled in browser flags.
2. What is the minimum OS, not the minimum browser? For anything touching WebGPU the honest answer is iOS 26 and Android 12, and that should appear in your compatibility notes, not in a footnote.
3. Has it been tested on Exynos Samsung hardware? If the developer looks blank, they have tested on Pixel and iPhone and called it Android coverage.
4. Is the WebGPU path switchable off at config, without a rebuild? If it is not, you have no lever when it misbehaves in production, and you will be waiting on the licensor's release cycle.
5. Who pays for a fix if the fallback breaks after a browser update? This belongs in the licence terms, not in an email thread eight months later.

That last one is the one operators skip and then regret. A rendering path that depends on browser vendor behaviour is a maintenance obligation with no fixed end date, and licences generally do not say who owns it.

🌲 Where This Lands

The defensible position for most catalogue operators in 2026 is unglamorous: target WebGL2, verify the games actually run on a four-year-old mid-range Android and an iPhone that cannot take iOS 26, and treat any WebGPU path as an optional extra you can switch off rather than a feature you paid for. Revisit when Firefox has shipped on Android and Linux, and when the gpuweb wiki's Samsung row turns green. Both are plausible within a year. Neither has happened.

Forestry Games has licensed HTML5 and Android games since 2017, and the compatibility floor is a question we get from portal operators and telecom buyers far more often than any question about visual fidelity — because the buyer's problem is never "can this look better on a flagship," it is "does this run on everything my users own." If you want to see what a broad catalogue looks like when it is specified against the low end rather than the demo reel, the full catalogue is the place to start.

The next action is smaller than a strategy: open your own analytics, pull the OS version split for your last 30 days rather than the browser split, and calculate what share of your traffic sits below iOS 26 and Android 12. Whatever that number is, it is the real ceiling on any WebGPU decision you make this year — and it is almost certainly not 85%.