Home → Learn → Browser fingerprinting

Browser fingerprinting, explained

Cookies identify a browser that agrees to be identified. Fingerprinting identifies it anyway — from the way it draws text, the GPU behind it, the fonts installed, the clock it keeps. Here is what each signal actually is, and why the obvious defence usually makes things worse.

What a fingerprint is

A browser fingerprint is the combination of properties a website can read without asking permission. No single one identifies you. Millions of people share your screen resolution; millions share your timezone. The identifying power is in the combination — once you join twenty low-information signals together, the set that matches all of them is often just you.

That matters for anyone running more than one account, because the fingerprint travels between accounts. Log into two accounts from one browser and they share a canvas hash, a GPU string, a font list and a clock. Clearing cookies changes none of that.

Canvas fingerprinting

The page draws text and shapes to an invisible <canvas>, then reads the pixels back as data. Identical drawing instructions do not produce identical pixels across machines: anti-aliasing, sub-pixel rendering, the font actually chosen, and the GPU doing the rasterising all shift the output slightly. Hash those pixels and you get a stable per-machine value.

It is cheap, silent, needs no permission, and has been in production use since around 2012. It remains one of the strongest single signals available.

WebGL and the GPU

Through WEBGL_debug_renderer_info, a page can ask for the unmasked GPU vendor and renderer — strings like ANGLE (Intel, Intel(R) UHD Graphics 630 … Direct3D11). That identifies the graphics hardware, the driver, and by implication the operating system and roughly the age of the machine.

It is also the signal that most often catches a disguise. The renderer string comes from the real driver. A browser claiming Windows in its user agent while reporting Apple Metal hardware is not a combination that exists on a real machine.

Audio fingerprinting

The same idea as canvas, applied to sound. The page renders a tone through an OfflineAudioContext — nothing is audible — and hashes the resulting samples. Floating point output varies slightly with the audio stack, giving another stable value that costs nothing to collect.

Font enumeration

A page cannot list your fonts directly, so it measures. It renders the same string in a candidate font and in a generic fallback; if the widths differ, the candidate is installed. Repeat a few hundred times and you have a font list.

Fonts are unusually revealing because they accumulate from what you install. Office, design tools, language packs and games all leave traces, and the resulting set is often close to unique.

User agent and client hints

The user-agent string is the oldest signal and the least trusted now. Chromium has been reducing it for years in favour of client hints — Sec-CH-UA, Sec-CH-UA-Platform, Sec-CH-UA-Mobile — sent as headers and readable via navigator.userAgentData.

Timezone, locale and IP

Intl.DateTimeFormat().resolvedOptions().timeZone gives the IANA zone — Europe/Berlin, Asia/Kolkata. Alongside it sit navigator.language and the accepted-languages header.

These are checked against your IP. A German residential proxy, a browser reporting America/New_York, and a locale of en-US describe three different people. This is the single most common self-inflicted flag in multi-account work, and the easiest to avoid: when you assign a proxy, match the timezone and locale to it.

WebRTC leaks

WebRTC negotiates peer-to-peer connections, and to do that it gathers candidate addresses — including ones the page was never given. Historically this exposed the real IP straight through a proxy: the page saw the proxy's address in the request and the true address in the ICE candidates.

Modern Chromium masks local addresses behind .local mDNS hostnames, which closes the worst of it, but the public-address path still matters when a proxy is in play. It is worth testing rather than assuming — the fingerprint test shows you exactly what WebRTC hands out on your setup.

Why blocking backfires

The instinct is to block everything: refuse canvas reads, strip the user agent, disable WebGL. This usually makes you more identifiable, for a simple reason — almost nobody does it.

A browser that refuses canvas, reports no fonts and exposes no GPU is not blending into the crowd; it is a member of a very small crowd. Randomising per page load is worse still: a fingerprint that changes on every visit is itself a fingerprint, and an obvious one.

Coherence beats hiding

The goal is not to be invisible. It is to be unremarkable, and different per account. That means every profile presents a full set of signals that agree with each other: the GPU matches the claimed OS, client hints match the user agent, the timezone matches the proxy, the fonts match the platform, the screen size is one a real device ships with.

Getting that combination right by hand is where most setups fail — there are dozens of values and they constrain each other. Running multiple profiles covers how the separation works in practice.