WebGPU Fingerprinting: The Next Generation After Canvas and WebGL

WebGPU shipped in Chrome 113 in 2023. By 2026, it's available across all major browsers on all major platforms. Unlike WebGL — which was a browser API wrapping OpenGL ES 2.0 — WebGPU is a direct interface to modern GPU APIs: Vulkan on Linux, Metal on macOS, DirectX 12 on Windows.

This changes what a browser can query about the underlying hardware. Canvas and WebGL fingerprinting relied on rendering outputs. WebGPU allows direct capability queries against the GPU itself, exposing architectural details that rendering output can only hint at.

For fingerprinting, this is a step-function improvement in signal quality.

What WebGPU exposes that WebGL doesn't

WebGL's diagnostic surface is limited. The most useful piece is the WEBGL_debug_renderer_info extension, which returns vendor and renderer strings — often spoofed by antidetect browsers or stripped by privacy features.

WebGPU provides GPUAdapter and GPUAdapterInfo objects with substantially richer data:

• Vendor — the GPU manufacturer identifier (NVIDIA, AMD, Intel, Apple, Qualcomm).
• Architecture — the GPU architecture family (Ampere, RDNA 2, Xe-LP, Apple M2, Adreno).
• Device — the specific model where available.
• Description — a human-readable string.

Beyond identification, WebGPU exposes GPU limits — the exact numeric capabilities of the hardware. These are queryable through the GPUSupportedLimits interface and include over 30 numeric properties:

• Maximum texture dimensions — maxTextureDimension2D
• Maximum buffer size — maxBufferSize
• Maximum bind groups — maxBindGroups
• Maximum compute workgroup dimensions
• Maximum vertex attributes
• Storage buffer alignment requirements

Each of these values is set by the GPU driver based on hardware capability. Different GPU generations, even within the same vendor, have different limit combinations. A 2019 GPU has different limits than a 2023 GPU from the same vendor family.

Why this is harder to spoof

Antidetect browsers spoof Canvas and WebGL by intercepting the API calls and modifying results. Canvas returns are hashes of rendered pixels — the browser can render, then swap the hash. WebGL is queried for a small number of strings that can be replaced wholesale.

WebGPU is different. The API surface is large — hundreds of methods and properties. Every call needs a plausible return value. A spoofing layer must:

• Present a consistent identity across all the numeric limits — a GPU claiming to be an NVIDIA RTX 4090 must return every limit value that matches that hardware.
• Handle actual compute execution. WebGPU allows running compute shaders. If a spoofing layer claims high performance but delivers slow compute, the mismatch is detectable through timing.
• Track evolution across driver updates. Each GPU driver version has slightly different limits. Static spoofing tables become outdated as new driver versions release.

Real hardware provides all of this for free. Spoofing hardware requires maintaining a database of true limit combinations per GPU model per driver version — an ongoing maintenance burden that most antidetect browsers haven't taken on yet.

Compute performance as a fingerprint

WebGPU allows running arbitrary compute shaders in the browser. This means detection systems can execute standardized workloads and measure how long they take.

A hash-cracking benchmark, a matrix multiplication, or a rendering-adjacent compute task all run at speeds determined by the underlying hardware. Two visitors claiming to have the same GPU model but delivering different compute performance are lying about hardware.

The technique bypasses static fingerprint spoofing entirely. A visitor can claim any GPU string they want. They cannot claim a compute performance they don't have.

The tradeoff is user experience. Running a compute shader in the background consumes GPU cycles and can be perceived as sluggishness. This limits how aggressively the technique can be used — typically as a one-time check on suspicious sessions rather than continuous monitoring.

Feature availability as a signal

WebGPU exposes optional features through GPUAdapter.features. Some GPUs support specific extensions:

• timestamp-query — requires modern GPU with performance counters
• shader-f16 — half-precision floating point, common on mobile GPUs
• texture-compression-bc — Block Compression, standard on desktop
• texture-compression-etc2 — mobile texture format
• texture-compression-astc — mobile texture format

The feature set is deterministic per GPU model. A Windows machine claiming to have Adreno mobile features is caught. A mobile device claiming desktop-only compression formats is caught.

Coherence with WebGL

Before WebGPU, browsers had one primary GPU query surface: WebGL. Now they have two, and they must agree.

WebGL and WebGPU expose the same underlying GPU. Their responses must be consistent. A browser reporting NVIDIA RTX 4080 through WebGL but returning WebGPU limits matching an integrated Intel GPU is impossible on real hardware.

Cross-API consistency is another signal for detection. Spoofing one API is straightforward. Spoofing two APIs in a mutually-consistent way is significantly harder — and current antidetect browsers largely don't do it.

What WebGPU exposes about the OS and driver

Beyond GPU identification, WebGPU exposes context about the graphics stack:

• On Windows, WebGPU can reveal whether Direct3D 11 or Direct3D 12 is being used, which correlates with OS version and driver era.
• On macOS, Metal version support reveals macOS version — because Metal versions ship with OS updates.
• On Linux, Vulkan support levels expose distribution and driver origin (proprietary NVIDIA vs. open-source Mesa, for example).

None of these signals are direct — each requires interpretation. But taken together, they build a picture of the underlying software stack that correlates with the reported browser fingerprint. Mismatches indicate spoofing.

Timeline for adoption in detection stacks

WebGPU fingerprinting is not yet a mainstream detection technique in 2026, for three reasons:

1. Browser support is still stabilizing. Firefox WebGPU shipped in 2024, but with limited feature coverage. Safari WebGPU shipped in 2024 but with different limits than Chrome. Detection systems need broad coverage before they can rely on WebGPU signals.
2. Real user WebGPU support is still incomplete. Older devices don't have GPUs that support WebGPU features. A detection system that penalizes visitors without WebGPU risks blocking legitimate users on 5-year-old hardware.
3. Antidetect browsers have not yet built out full WebGPU spoofing, which means WebGPU-based signals are currently effective against sophisticated attackers who assume they've hidden their tracks. This will change as detection adoption increases and spoofing tools respond.

The 2–3 year adoption horizon is realistic. By 2027–2028, WebGPU signals will be as central to bot detection as WebGL is today. The question for detection teams is when to start collecting WebGPU data — the answer is now, so the historical baseline exists when the signals become primary.

What this means for defenders

Canvas fingerprinting is a mature technique. WebGL fingerprinting is a mature technique. Both are actively being spoofed by antidetect tooling with reasonable success.

WebGPU fingerprinting is a young technique. Spoofing tools haven't caught up. This creates a window — probably 18–36 months — where WebGPU signals cleanly separate real users from sophisticated bots. That window is worth investing in.

The signals it produces are also structurally harder to spoof than Canvas or WebGL. Rendering can be intercepted. Compute performance cannot. Feature sets can be lied about, but not consistently across the whole API surface. Each generation of fingerprinting technique raises the cost of spoofing. WebGPU raises it substantially.

For platforms serious about bot detection in 2026 and beyond, WebGPU is where the signal is moving.