WebGL Fingerprint Test

WebGL exists so that a web page can draw 3D graphics without a plugin. To do that, the browser has to hand the page a real graphics context, and that context comes with a description of the hardware behind it. The vendor, the renderer, the driver's shader extensions and a long list of numeric limits all become readable to any script that asks.

That description is a fingerprinting goldmine because it is hardware-shaped. Your canvas hash can drift with a browser update, but your GPU and driver version stay put for months. The widget above opens a context, reads every parameter a fingerprinting script typically collects, and reduces the set to a single 32-character hash so you can see how stable the picture is between visits.

Every WebGL context exposes two strings by default. VENDOR and RENDERER are the masked forms, and browsers deliberately keep them vague, often returning values such as WebKit or WebKit WebGL so that a page cannot read the hardware directly. On their own they are not very useful to a tracker.

The precise names come from a separate, optional extension called WEBGL_debug_renderer_info. When it is present, its UNMASKED_VENDOR_WEBGL and UNMASKED_RENDERER_WEBGL parameters return the real strings, for example Google Inc. (NVIDIA) and a renderer line naming the GPU, the Direct3D feature level and the driver path. The widget lists both pairs so you can see exactly what your browser chooses to disclose.

Whether the extension is exposed is a policy decision, not a hardware one. Two identical laptops running different browser settings will show different amounts here, which is why the block above labels it as exposed or blocked rather than treating it as fixed. The graphics card test walks through the same strings from a hardware-identification angle.

Beyond the names, a WebGL context answers questions about its own capabilities. getSupportedExtensions() returns the shader features the driver offers, from compressed texture formats such as WEBGL_compressed_texture_s3tc to depth-texture and instancing extensions. A WebGL2 context on a modern desktop GPU typically reports somewhere between forty and sixty of them; a software renderer reports far fewer, and the exact list is a strong hint about the driver.

The numeric parameters are just as revealing. MAX_TEXTURE_SIZE is 16384 or 32768 on most discrete and integrated GPUs but can be 4096 on older or virtualised hardware. MAX_VIEWPORT_DIMS, MAX_VERTEX_ATTRIBS, the aliased line-width range and the uniform vector counts all vary by driver, and taken together they form a combination that is far more specific than any single value.

A missing unmasked renderer is normal, not a fault in your machine. Firefox generalises these strings on desktop as part of its fingerprinting resistance, and Safari limits the extension too, so you may see only the masked values and a generic vendor. Neither behaviour means WebGL is broken: drawing still works, and the limits and the extension list still come through.

The driver blocklist is a separate reason the name can disappear. Browsers keep a list of driver versions known to crash or render incorrectly, and when yours is on it the browser falls back to a software rasteriser. You will meet names such as SwiftShader on Chromium and llvmpipe on Linux and Firefox. That fallback is deliberate, and the panel reports it honestly rather than hiding it.

In fingerprinting research, the graphics stack is consistently one of the highest-entropy signals a page can read without permission. There are hundreds of GPU models, each with many driver versions, each exposing a slightly different extension set and limit table. A page that reads all of it can often place your machine in a group far smaller than the one your user agent puts you in.

It is also hard to fake convincingly. Overriding navigator.userAgent is a one-line change, but a spoofed renderer string that does not match the extension list, the texture limits and the canvas output underneath it stands out immediately. That mismatch is exactly what the browser fingerprint test looks for when it audits whether your signals agree with one another.

It is worth being precise about the limits. A renderer string identifies a model, not a specific card, and it certainly does not identify a person. Any script that stores only the hash cannot tell two users of the same hardware apart, and cannot tell whether the value it holds belongs to one visitor or a thousand. The device hardware info test shows how coarse those hardware facts really are on their own.

WebGL can also be switched off. Some hardened browsers disable it outright, virtual machines fall back to a software rasteriser such as SwiftShader or llvmpipe, and remote desktops often report a generic adapter. In those cases the signal collapses to a value shared by everyone in the same situation, which makes it useless for tracking and makes the browser look unusual at the same time.

WebGL is hard to fake well, and that shapes what is worth doing. Overriding one string through an extension is easy, but a renderer that disagrees with the extension list, the texture limits and the canvas underneath it is a contradiction a fingerprinting script can spot in a single pass.

The options that work are the blunt ones. A browser that reports generic values or adds noise, such as Firefox in its strict mode or Brave, reduces the signal without breaking 3D content. Disabling WebGL entirely is effective and costly, because maps, games and many data visualisations stop rendering, though some hardened browsers accept that trade.