Intent to Ship: WebGPU Compatibility mode

[Chromestatus]

Contact emails

senor...@google.com, kai...@google.com

Explainer

https://github.com/explainers-by-googlers/webgpu-compatibility-mode/blob/main/README.md

Specification

https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md

Summary

Adds an opt-in, lightly restricted subset of the WebGPU API capable of running older graphics APIs such as OpenGL and Direct3D11. By opting into this mode and obeying its constraints, developers can extend the reach of their WebGPU applications to many older devices that do not have the modern, explicit graphics APIs that core WebGPU requires. For simple applications, the only required change is to specify the "compatibility" featureLevel when calling requestAdapter. For more advanced applications, some modifications may be necessary to accommodate the mode's restrictions. Since Compatibility mode is a subset, the resulting applications are also valid WebGPU Core applications and will run even on user agents that do not support Compatibility mode.

Blink component

Blink>WebGPU

Web Feature ID

webgpu

Motivation

WebGPU is a good match for modern graphics APIs such as Vulkan, Metal and Direct3D 12. However, there are a large number of devices which do not yet support those APIs. In particular, on Chrome on Windows, 31% of Chrome users do not have Direct3D FL 11.1 or higher. On Android, 23% of Android users do not have Vulkan 1.1, including 15% who do not have Vulkan at all (https://developer.android.com/about/dashboards). On ChromeOS, Vulkan penetration is still quite low, while OpenGL ES 3.1 is ubiquitous. Developers are thus forced to write multiple implementations (e.g., WebGPU and WebGL) for maximum reach, to accept the reduced reach that core WebGPU currently provides, or to write only for WebGL and forgo the advanced features of WebGPU, such as GPU compute. By opting in to Compatibility Mode, developers can target a wider reach of devices with a single implementation.

Initial public proposal

https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md

TAG review

https://github.com/w3ctag/design-reviews/issues/1063

TAG review status

Issues addressed

Origin Trial Name

WebGPU Compatibility Mode

Chromium Trial Name

WebGPUCompatibilityMode

Origin Trial documentation link

https://github.com/explainers-by-googlers/webgpu-compatibility-mode/blob/main/README.md

WebFeature UseCounter name

kWebGPUFeatureLevelCompatibility

Risks

Interoperability and Compatibility

This feature has been approved in W3C GPU for the Web WG meetings including participants from Safari and Firefox.

Gecko: Positive Although there is not currently an entry for Compatibility Mode in the standards positions repos, WebGPU Compatibility Mode was discussed and approved by Google, Apple and Mozilla in the GPU for the Web Working Group, and has the same support as WebGPU Core. Each of the commits to the compatibility-mode propsal above was approved by a working group member from each of those three organizations, and any disagreements were resolved prior to landing in Working Group meetings.

WebKit: Positive Although there is not currently an entry for Compatibility Mode in the standards positions repos, WebGPU Compatibility Mode was discussed and approved by Google, Apple and Mozilla in the GPU for the Web Working Group, and has the same support as WebGPU Core. Each of the commits to the compatibility-mode propsal above was approved by a working group member from each of those three organizations, and any disagreements were resolved prior to landing in Working Group meetings.

Web developers: No signals

Other signals:

Security

Being a lightly-restricted subset, Compatibility Mode does not introduce any accessibility, security, or privacy issues over and above those introduced by core WebGPU. For this reason, the security review submitted for WebGPU also applies to Compatibility Mode.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Low; does not remove or alter existing APIs. Provides a lightly-restricted subset of the WebGPU API to older devices which are not capable of the core WebGPU API In case of emergency, there are two independent killswitches: - kWebGPUAndroidOpenGLES controls the Dawn OpenGLES backend on Android in the GPU process - RuntimeEnabledFeature kWebGPUCompatibilityMode controls the JS API in the renderer process

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No
All platforms will eventually have support. Will immediately be available on Android, Android WebView, ChromeOS, Mac, and Windows, where hardware support is available. Linux is planned to have WebGPU support in the future, so this feature will become available when WebGPU does.

Is this feature fully tested by web-platform-tests?

Yes
All Compatibility Mode restrictions are exercised by the "compatibility" option to the WebGPU CTS. E.g., https://gpuweb.github.io/cts/standalone/?compatibility=1&q=webgpu:* This subset is tested extensively on the Dawn CI (https://ci.chromium.org/p/chromium/g/chromium.dawn/console) under the "webgpu_cts_compat_tests" suite. WebGPU/WGSL have a conformance test suite (https://github.com/gpuweb/cts) that is regularly pulled into Chromium and part of the testing of Dawn/Tint in Chromium. While the CTS can be embedded in WPT, the WebGPU team opted to keep it separate in Chromium testing to use a customized harness for robustness and performance.

Flag name on about://flags

No information provided

Finch feature name

WebGPUCompatibilityMode

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://crbug.com/442618060

Availability expectation

Mozilla is interested in this feature (and has approved all of the spec changes) but has not committed to implementing it yet. Apple has approved all of the spec changes, but it is not anticipated that this feature will ship in Safari since all Apple devices on the market can support the full Core WebGPU spec. However, since it is designed as a subset, Compatibility mode applications will work unchanged in browsers that only support Core (e.g., Safari).

Adoption expectation

Feature is used by specific partner(s) to provide functionality within 12 months of launch in Chrome.

Adoption plan

Adoption of Core WebGPU proceeds apace (https://chromestatus.com/metrics/feature/timeline/popularity/4029), and it is expected that developers will adopt Compatibility Mode because it allows them to extend the reach of their WebGPU content to a larger audience.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

On Android, this feature depends on the OpenGLES 3.1 graphics API in order to provide WebGPU capability to older devices. The JavaScript API will be available on all platforms, including desktop, but will not require any new graphics APIs; it will simply allow developers to test the Compatibility Mode subset on all Chrome platforms.

Estimated milestones

Shipping on desktop	146
Origin trial desktop first	139
Origin trial desktop last	145
Shipping on Android	146
Origin trial Android first	139
Origin trial Android last	145
Shipping on WebView	146
Origin trial WebView first	139
Origin trial WebView last	145

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

All Compatibility Mode changes have landed in the WebGPU core spec: https://www.w3.org/TR/webgpu/; all known issues have been addressed.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6436406437871616?gate=6221450639572992

Links to previous Intent discussions

Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/683618d7.170a0220.2aa17e.17c5.GAE%40google.com

This intent message was generated by Chrome Platform Status.

[Yoav Weiss (@Shopify)]

On Tuesday, January 13, 2026 at 9:16:24 PM UTC+1 Chromestatus wrote:

Contact emails

senor...@google.com, kai...@google.com

Explainer

https://github.com/explainers-by-googlers/webgpu-compatibility-mode/blob/main/README.md

Specification

https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md

Can you point to a PR or a spec section that includes the change?

[Stephen White]

Sure! The above proposal was converted into spec text on a feature branch. This is the merge commit that brought those changes into the main spec. The changes are not isolated to a single section, but each restriction appears in a cyan box labelled "Compatibility Mode", easiest to find by searching for "core-features-and-limits".

These are the (largely minor) followup changes that landed after that merge:

• Disallow cube-array in createTexture
• Fix maxStorageTexturesIn*Stage defaults
• [editorial] Tweak requestAdapter step ordering, feature level definitions (again)

Stephen

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2c05e366-fc6b-453d-a4a6-86f3c38076f9n%40chromium.org.

[Alex Russell]

It's a little odd that there's no developer feedback here. Is it correct that we're shipping first? And is there a list of features that will not be available in this mode? Does it unlock software rendering?

Thanks,

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Kai Ninomiya]

On Wed, Jan 14, 2026 at 8:05 AM Alex Russell <sligh...@chromium.org> wrote:

It's a little odd that there's no developer feedback here.

Fair point. The main impact is just "you can ship on more devices", which developers certainly want, but of course WebGPU must still be usable with the restrictions. We do have positive feedback on that, which we will follow up with shortly.

 

Is it correct that we're shipping first?

Yes, but more than that, we don't expect all browsers to ship it ever. Compatibility mode was specifically designed to interoperate as well as possible with other browsers that never implement it (Safari), and Safari+Firefox have reviewed the API thoroughly in the WG and approved it with this in mind. It is expected to be a positive force for WebGPU adoption overall as it reduces the need for applications to continue to support WebGL.

Firefox is considering implementing Compatibility Mode, but of course it competes with their priorities for other WebGPU features. (Compatibility Mode is mostly for old and very-low-spec/below-baseline Android devices, which are relatively more critical for Chromium as a core Android system component.)

 

And is there a list of features that will not be available in this mode?

The detailed proposal doc enumerates them:

https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md

That should be complete, but of course the final details are in the spec itself.

 

Does it unlock software rendering?

No, only hardware rendering on more devices (that are less capable).

These days, software renderers (WARP, Lavapipe) are among the more capable implementations of graphics APIs, since they have no hardware dependency and can implement anything with sufficient effort (which has been happening).

-Kai (he/they)

(Google)

 

Thanks,

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.