WebGL lets pages ask your graphics card to identify itself. Here is what a site learns from your GPU, why those strings identify you, and what browsers do.
On this page
A page loads with a 3D model on it, and before the first frame appears a quiet exchange has already taken place. The script asks the browser for a rendering context. The browser turns to your graphics driver and asks what the card underneath it can do, because a scene that runs on one card may not run on another. The driver answers in full: who made the hardware, which model it is, which driver revision is installed, which optional features it advertises. None of it was hidden from the page. The page needed the answer to draw the model correctly. It did not need any of it to recognise you.
Where the web uses WebGL
Most fingerprinting signals describe your software: the browser version, the language, the time zone. WebGL is different. It is the browser’s interface to the GPU, the processor that handles graphics, and everything it reports is about the machine rather than the settings.
Games, 3D product viewers, map rendering and data visualisations all rely on it. When a page wants to draw something, it opens a rendering context and asks the driver which features are available, because a scene that runs on one card may not run on another.
That conversation is entirely legitimate. It is also involuntary. To render correctly, the page must know your hardware, and the same information that helps it draw a spinning model helps it single you out. That is the awkward part: the detail that makes the web work is the detail that identifies you.
The strings your driver hands over
The clearest signals come from a short set of strings the driver exposes. You can see yours with the WebGL fingerprint test.
| String | What it tells a page |
|---|---|
| Vendor string | Who made the graphics hardware |
| Renderer string | The exact model, and often the driver |
| Unmasked values | The raw identifiers beneath the placeholders |
The vendor string names the maker in the driver’s own words. It may read as a familiar manufacturer or, on some systems, as a generic placeholder. The renderer string carries the specific model and often the driver version with it, and it is the single most identifying line in the whole WebGL output. The unmasked values come from a debugging extension, where it is available; that extension can strip away the anonymised placeholders browsers sometimes substitute and return the raw identifiers underneath.
A model number alone is common enough. A model combined with a particular driver build, a browser version and an operating system is far rarer, because driver releases differ by OEM, by region and by when the machine was last updated.
Extensions and shader precision
Two further categories of detail add weight to the picture.
Supported extensions
The list of supported extensions describes optional capabilities the driver advertises. Different cards, driver generations and platforms expose slightly different sets, so the exact combination is another quiet differentiator, one more value that narrows the crowd.
Shader precision
Shader precision is subtler still. WebGL programs calculate in floating-point numbers, and drivers report how many bits of precision those calculations actually carry: how many bits the exponent uses, how many the mantissa. Those values vary with the GPU architecture. Because they change the numerical output of a rendered scene, they also shift the pixels a little, which is what makes them worth measuring.
Reading the pixels, not just the strings
Strings are easy to read but easy to fake, so serious fingerprinting does not stop there. It renders an actual 3D scene — complex geometry, textured surfaces, lighting — then reads the image back and hashes it, exactly as canvas fingerprinting does with a flat drawing.
The result blends the reported strings with the physical behaviour of the hardware: how the driver handles texture filtering, blending and anti-aliasing. Two machines reporting the same GPU model can still produce slightly different images if their drivers or settings differ.
For a closer look at the card itself, the graphics card test reports what your browser can detect about the hardware. The device hardware info page shows the wider picture of what else your machine gives away.
Why a GPU row is so identifying
The identifying power comes from how uneven the hardware landscape is.
| Setup | What the page sees | Why it is uncommon | What it does for a tracker |
|---|---|---|---|
| Unusual driver build | Whatever the manufacturer shipped, at an exact revision | The revision trails behind and varies by device | Narrows the field sharply |
| Integrated or discrete graphics | Whichever GPU is active at the time | A laptop that switches between two reports only one | Carries information on its own |
| A virtual machine or cloud desktop | A generic or virtualised renderer | Almost nobody runs one locally | Picks those users out easily |
| A headless or automated browser | A default or software renderer | It is driven without a screen | Another uncommon value |
Two properties make the signal durable as well as rare.
- It is hard to change. Fixing it means new hardware, not a new setting.
- Few users share one. A precise configuration — model, driver build, browser version, operating system — is uncommon.
For a tracker, the WebGL row is often one of the most valuable in the whole fingerprint.
How Brave handles WebGL
Brave intervenes at the source. It can block WebGL entirely, or feed the page a randomised or genericised result so the value is not stable from one session to the next. A tracker that cannot get the same answer twice cannot use it to recognise you.
What Firefox does instead
Firefox relies on its resist-fingerprinting setting. Rather than randomising the values, it leans on standardisation and prompt-based controls, and it can ask before granting WebGL access, so the page learns nothing unless you agree. The approach is more conservative, but it keeps pages working.
What the defence costs you
Neither route is free, and it is worth seeing the trade-off plainly.
What it does well
- Breaks the stable value a tracker needs
- Can hold the page back until you agree
- Leaves ordinary pages working on the conservative route
Where it falls short
- Blocking or perturbing WebGL can break legitimate 3D content
- Looking unlike the default crowd is, ironically, a signal of its own
The point is not that either browser is wrong: a defence against a hardware signal has to make a choice, and either choice leaves a mark.
Check both on your own machine
The practical first step is awareness, and it costs nothing. See what your own card announces with the WebGL fingerprint test, then run the graphics card test to see what your browser can detect about the hardware behind it. Put both beside the rest of your browser fingerprint and the picture is complete.
WebGL fingerprinting matters because it reaches past your settings and into your hardware, and because the details it returns are precise enough that you cannot casually change them. For how those signals combine with everything else, what is browser fingerprinting is the place to start.