How Does Browser Fingerprinting Work?
Learn how browser fingerprinting builds an identifier from JavaScript-readable attributes, why entropy and consistency matter more than any single value, and its limits.
Browser fingerprinting identifies a visitor by combining dozens of attributes the browser exposes to JavaScript. No single attribute is identifying. The combination frequently is — and unlike cookies, there is nothing to clear.
1. The Core Mechanism
A script runs in the page and reads properties the browser makes available: screen dimensions, timezone, language, installed fonts, GPU details, hardware capabilities, and the precise output of certain rendering operations.
Each value narrows the population. Timezone might split visitors into a few dozen groups; screen resolution into a few hundred; font list into thousands. Multiply enough weak signals together and the result is often unique.
The technical term is entropy — how much a value narrows the field. Fingerprinting is the practice of stacking low-entropy signals until their combination is high-entropy.
2. What Gets Collected
| Category | Examples |
|---|---|
| Screen | Resolution, colour depth, pixel ratio, available area |
| Locale | Timezone, language list, date and number formatting |
| Hardware | CPU cores, device memory, touch points |
| Graphics | WebGL vendor and renderer, shader precision |
| Rendering | Canvas and WebGL output hashes |
| Audio | AudioContext processing output |
| Fonts | Which fonts render, measured by text dimensions |
| Browser | User agent, platform, plugins, supported APIs |
| Network | Connection type, WebRTC-exposed addresses |
| Behaviour | Mouse movement, timing, scroll dynamics |
3. Canvas and WebGL — The High-Entropy Signals
These carry disproportionate weight, and it is worth understanding why.
The script draws text or a 3D scene to an off-screen canvas and reads back the pixels. The instruction is identical for everyone; the output is not. GPU model, driver version, anti-aliasing behaviour, font rasterisation and OS compositing all subtly alter the rendered pixels.
Hash those pixels and you get a value that is stable for one machine and varies across machines — from a rendering operation the user never sees.
WebGL adds the vendor and renderer strings, which name the actual graphics hardware. That combination alone splits the population finely, and it is why headless environments with software rendering stand out: their renderer string does not match any consumer GPU.
4. Consistency Matters More Than Any Value
Detection is less interested in what your fingerprint says than in whether its parts agree.
A real device is internally coherent. A spoofed one usually is not:
- User agent claims Windows; WebGL renderer reports a Linux Mesa driver.
- User agent claims iPhone; screen is 1920×1080 and there is no touch support.
- Timezone is Asia/Tokyo; language list is en-US only; IP geolocates to Germany.
- Platform says macOS; the font list contains no macOS system fonts.
navigator.webdriveris absent, but automation-specific properties remain on the object.
Each contradiction is a stronger signal than an unusual value, because unusual configurations genuinely exist while impossible ones do not. This is why partial spoofing tends to make things worse: changing the user agent alone creates mismatches that a plain, unmodified environment never has.
5. What It Is Used For
- Fraud prevention. Recognising a device across sessions and cleared cookies.
- Bot detection. Spotting automation environments and impossible combinations.
- Account security. Flagging logins from a device that has never been seen.
- Rate limiting by device rather than by IP, which survives proxy rotation.
- Tracking, the use that drives most of the privacy legislation and browser countermeasures around it.
6. Limits and Countermeasures
Fingerprinting is not infallible.
- It drifts. Browser updates, driver updates, a new monitor or an installed font all change it.
- Common configurations collide. A default iPhone is one of millions producing near-identical values.
- Browsers actively resist it. Safari reports simplified values, Firefox blocks known fingerprinting scripts, Tor deliberately makes all users look alike.
- Randomisation cuts both ways. Adding noise per session defeats linking, but a fingerprint that changes on every page load is itself an anomaly.
The most durable evasion is not spoofing at all — it is presenting a genuinely ordinary environment, because the goal is to be unremarkable rather than to be hidden.
7. Real-World Examples
- Blocking that follows you across every proxy — the identifier was the device, not the address.
- A headless browser flagged by its WebGL renderer reporting SwiftShader instead of real hardware.
- A user-agent switcher making detection worse by introducing contradictions with the rest of the surface.
- A returning visitor recognised after clearing all storage, because nothing was stored to clear.
- A stable setup breaking after a driver update, when canvas output shifted and the device read as new.
8. Summary
Browser fingerprinting combines many low-entropy attributes — screen, locale, hardware, fonts, and rendering output from canvas, WebGL and audio — into an identifier that is often unique and requires no stored state.
Canvas and WebGL contribute the most because they expose hardware and driver behaviour indirectly. But detection weights internal consistency above any individual value: impossible combinations are far more revealing than unusual ones, which is why partial spoofing routinely backfires.
It is powerful and imperfect: fingerprints drift with updates, common devices collide, and browsers increasingly resist it by design.