WebGPU Fingerprinting: Adapter and Limits Signals Explained

WebGPU is the successor to WebGL, and it leaks far more about the underlying hardware than most teams realize. Where WebGL exposed a renderer string, WebGPU hands you an adapter, an architecture label, and a table of numeric limits that together narrow a device to a small population.

What WebGPU actually exposes

When a page calls navigator.gpu.requestAdapter() and then adapter.requestAdapterInfo(), the browser returns fields such as vendor, architecture, device, and description. On many systems this resolves to strings like nvidia and ampere, or apple and metal-3. These are coarser than raw WebGL renderer strings on some platforms because browser vendors deliberately bucket values to reduce tracking, but the bucketing itself is informative.

The richer source is adapter.limits. This object contains dozens of numbers: maxTextureDimension2D, maxBufferSize, maxComputeWorkgroupStorageSize, maxBindGroups, and more. Different GPU families and driver versions report distinct combinations. A mid-range integrated chip and a discrete workstation card produce clearly different limit tables.

Why the limits table matters for entropy

Any single limit is low entropy on its own. The power comes from the joint distribution. A vector of 30 limit values, hashed together, collapses into a stable identifier that correlates tightly with a GPU generation and driver stack.

• Stability: limits rarely change unless the user updates a driver or swaps hardware, so the signal persists across sessions.
• Spoof resistance: faking one WebGL string is trivial, but forging an internally consistent WebGPU limits table plus a matching adapter architecture is much harder.
• Cross-check value: the limits should agree with the WebGL renderer, the reported screen, and the platform. Mismatches are a strong tamper indicator.

That last point is where WebGPU earns its keep. An anti-detect browser might spoof a Intel Iris WebGL string while the WebGPU adapter still reports apple. Prynt flags that contradiction rather than trusting either value in isolation.

Handling absence and compute-shader probes

Absence is a signal too. Locked-down browsers, privacy modes, and many automation stacks either disable WebGPU or return a software adapter. A fallbackAdapter flag or a swiftshader-style description tells you the environment is virtualized or headless. Prynt records the reason WebGPU failed, not just that it failed.

Some fingerprinting research goes further and runs a small compute shader to measure timing or floating-point rounding behavior across GPU families. Prynt avoids heavy GPU workloads in the browser because they cost battery and add latency. The adapter info and limits table already deliver most of the discriminating power without running a kernel on the visitor’s device.

Where WebGPU sits in a multi-signal model

No serious device-intelligence system rests on one API. WebGPU is one of more than 20 entropy sources Prynt combines into a single stable visitorId. Screen metrics, audio, canvas, fonts, and network-level signals all contribute, and the model weights each by how much it discriminates and how easily it is forged.

Because Prynt is a cloud platform, the raw limits vector never has to be trusted from the client alone. Signals are collected in the browser, sent to our API, and correlated server-side against the reputation network, so a spoofed adapter string gets caught when it disagrees with everything else we see. You can watch these signals resolve live in the interactive playground and inspect exactly which values a real browser reports.

Timing and driver-version drift

One nuance worth planning for is drift. A driver update can shift a handful of limit values or change the adapter description string, which nudges the WebGPU hash without the underlying hardware changing. A naive system reads that as a brand-new device. Prynt guards against this by weighting the limits vector as one contributing feature rather than a standalone identifier, so a driver update moves the score slightly instead of breaking the visitorId. The same discipline applies across every signal: any single source can drift, so identity is anchored in the agreement of many rather than the exactness of one. This is why a cloud correlation layer matters. It can absorb the normal churn of driver and browser updates while still catching the abrupt, wholesale changes that signal a spoof or a swapped environment.

Practical guidance for teams

• Treat WebGPU presence, adapter architecture, and the limits hash as three separate features, not one.
• Always cross-validate against WebGL and platform. Agreement raises confidence; contradiction lowers it.
• Do not block visitors purely for lacking WebGPU. Many legitimate users run older or hardened browsers.
• Log the failure reason so a software adapter can be distinguished from a disabled API.

WebGPU will only grow more common, and its rich limits surface makes it one of the more durable client signals available today. Used carefully and cross-checked, it tightens a fingerprint without hammering the user’s device.

Start collecting stable device signals in minutes on the free tier and add WebGPU-aware detection to your stack.