What Your Graphics Card Reveals Through WebGL and WebGPU

Why browsers expose GPU details at all, how renderer strings differ between Chrome, Firefox and Safari, what WebGPU adds, and how each browser limits it.

Modern web pages can use the graphics processor directly, through WebGL and its successor WebGPU. That powers 3D maps, games, product configurators and machine-learning demos. It also means a page can learn something about the graphics hardware, which is one of the more identifying things a browser exposes.

Why the GPU is visible at all

Graphics drivers have bugs, and some bugs only appear on specific chips or driver versions. Developers of serious WebGL applications need to know what they are running on, so they can avoid broken features or choose a lighter rendering path. Both APIs therefore offer a way to ask "which GPU is this?", and browsers have to balance that need against fingerprinting.

WebGL renderer strings

WebGL has two layers of identification:

  • The standard RENDERER and VENDOR parameters.
  • The WEBGL_debug_renderer_info extension, which adds "unmasked" versions of both.

How browsers fill them differs:

  • Chromium browsers return placeholders ("WebKit WebGL") from the standard parameters and the real driver string from the extension. The string typically looks like ANGLE (NVIDIA, NVIDIA GeForce RTX 3060 Direct3D11 vs_5_0 ps_5_0, D3D11). ANGLE is the layer that translates WebGL onto Direct3D, Metal or Vulkan.
  • Safari reports a generic "Apple GPU" rather than the exact chip.
  • Firefox returns a sanitized renderer string, and marks the debug extension as deprecated. With privacy.resistFingerprinting enabled, the extension is disabled.

Beyond the strings, WebGL exposes dozens of capability values: maximum texture size, maximum viewport, supported shader precision, and the list of extensions. Their combination varies by GPU and driver. A page can also render a scene and read the pixels back, the same way canvas fingerprinting works.

What WebGPU adds

WebGPU exposes an adapter, the browser's handle to a physical or software GPU, with an info object containing vendor, architecture, device and description strings. MDN notes that this information is deliberately minimal, that browsers are likely to share different types and granularities of it, and that each field may be an empty string.

WebGPU support is still uneven:

  • Chrome and Edge: available on desktop since version 113 (ChromeOS, macOS and Windows), with Linux support for some GPUs since version 144.
  • Safari: available from version 26.
  • Firefox: enabled on Windows since version 141.

Software rendering and virtual machines

When hardware acceleration is off, or the browser runs in a virtual machine, WebGL falls back to a software renderer such as SwiftShader or llvmpipe. The renderer string says so. That is a strong hint about the environment, which is why automated browsers and bots often stand out here.

How identifying is it?

A mainstream integrated GPU in a popular laptop is shared by millions of people. A specific high-end or workstation card, or an unusual driver version, narrows things much further. On its own, the GPU string separates groups; combined with screen size, fonts and time zone, it contributes strongly to a fingerprint.

What limits it

  • Use a browser that generalizes these strings. Safari and Firefox coarsen them by default. Brave adds randomization to several graphics-related outputs.
  • Avoid spoofing extensions. A desktop GPU string next to a mobile user agent is a contradiction trackers can spot.
  • Keep hardware acceleration on unless you have a reason to switch it off. A software renderer is rarer than a common GPU.

The WebGL and WebGPU test shows exactly what your browser reveals, and which path the renderer string came from.

Sources

  1. MDN: WEBGL_debug_renderer_info
  2. MDN: GPUAdapterInfo
  3. MDN: WebGPU API
  4. W3C Group Note: Mitigating Browser Fingerprinting in Web Specifications