Browser Fingerprinting: What Sites Actually Read
A field-by-field tour of the values a website collects, from canvas and WebGL to audio, fonts, screen and timezone, and why a coherent identity beats a randomised one.
Browser fingerprinting is the practice of identifying a browser by the values it reports rather than by anything it stores. No cookie is needed. The browser simply answers the questions any web page is allowed to ask, and the answers together are distinctive enough to recognise again.
The values that get collected
Most fingerprinting scripts read from the same handful of surfaces.
The obvious ones
- The user agent carries the browser name, version and platform, and it goes out on every request.
- The screen reports width, height, colour depth, pixel ratio and the available work area.
- Language and timezone cover the locale the browser reports and the offset it calculates.
- Hardware hints give the reported processor count and, on some browsers, an approximate memory figure.
The rendering ones
These are the values people mean when they say fingerprinting, because they are indirect. A page asks the browser to draw something and then reads back exactly what was drawn.
- Canvas work renders text and shapes to an off-screen canvas and hashes them. The result varies with the graphics stack, fonts and anti-aliasing.
- WebGL exposes the graphics adapter's vendor and renderer strings, plus a hash of a rendered scene.
- Audio runs an oscillator through the audio processing graph and hashes the output. Floating-point behaviour differs slightly between stacks.
- Font detection measures text in candidate fonts and infers which are installed from which measurements differ.
The network ones
- The address the request arrives from, and what a geolocation database says about it.
- WebRTC, which can reveal addresses the connection would otherwise not expose.
- The order and content of TLS and HTTP handshake fields, which vary by client.
Why randomising every field is the wrong instinct
The intuitive defence is to change everything on every visit. It backfires, for two reasons.
The first is contradiction. Randomised fields do not know about each other. A user agent claiming Windows next to a WebGL renderer string that only ships on Apple hardware is a stronger signal than either value alone would ever have been. Real machines are internally consistent; only synthetic ones disagree with themselves.
The second is instability. An account that reports a different device on every visit is describing something no real person owns. Consistency over time is what an ordinary user looks like.
What a profile's identity covers
| Surface | Handled by |
|---|---|
| User agent and platform | Generated together, so the claimed platform matches the values around it |
| Screen and pixel ratio | Fixed per profile, drawn from sizes real displays actually report |
| Timezone and locale | Set per profile, and matched against the network route it uses |
| Canvas, WebGL and audio | Given a stable per-profile treatment, identical on every open |
| Fonts | A per-profile set consistent with the platform the profile claims |
| WebRTC | Constrained so it does not contradict the profile's network route |
Checking your own work
Open a profile and visit a fingerprinting test page. Several publish the values they read, free of charge. The two things worth checking are not what you might expect:
- Do the values agree with each other? Platform, fonts, graphics strings and timezone should describe one plausible machine.
- Are they the same as last time? Close the profile, open it again, reload the test. A profile whose values move between opens is not stable, and stability is the property that matters.
A rarity score on a test page is the least useful number there. It measures you against that page's visitors, who are overwhelmingly people testing antidetect browsers.
