Browser Fingerprinting Techniques: How Each Method Works

Browser fingerprinting techniques fall into two families. Active techniques run script in the page and read what the browser reports or renders: attributes, canvas, WebGL, audio, fonts and API support. Passive techniques read what the connection reveals without any script: headers, the TLS handshake, HTTP/2 settings and the TCP/IP stack. Trackers combine both, then weigh stability and consistency.

This guide walks through each technique: what it reads, why the value differs between machines, how stable it is, and what an inconsistent value looks like. If you want to check your own browser rather than understand the methods, start with our browser fingerprint test guide instead.

Two families of browser fingerprinting techniques

The W3C Privacy Interest Group note Mitigating Browser Fingerprinting in Web Specifications draws the line that most of the field uses:

• Passive fingerprinting uses information the browser sends anyway — HTTP headers, network-level traits, the IP address. The site does not need to run anything, and the user cannot see it happening.
• Active fingerprinting runs JavaScript (or, historically, plug-ins) to query properties or make the browser do work, then records the result.

The distinction matters for two reasons. Passive signals cannot be blocked by disabling scripts, and they come from outside the browser profile — from the operating system's network stack, from the TLS library, from the proxy. Active signals are richer, but every one of them is an API call that browsers can restrict, randomise or standardise.

Active techniques: what the page asks the browser

Attribute probing

The simplest technique reads properties the browser exposes directly: the User-Agent string, platform, language list, timezone, screen resolution and colour depth, device pixel ratio, logical CPU core count, reported device memory and maximum touch points.

Chromium-based browsers have reduced the default User-Agent string and moved detail into User-Agent Client Hints. Low-entropy hints (brand, major version, mobile flag, platform) are sent by default; high-entropy hints such as the full version, platform version, architecture and device model must be requested by the site. A fingerprinting script simply asks for them.

Individually these values are common. Their value to a tracker is in combination — and in whether they agree with each other.

Canvas fingerprinting

The script draws text, emoji and shapes to an off-screen canvas, reads the pixels back and hashes them. Font rasterisation, anti-aliasing, sub-pixel rendering and GPU compositing differ subtly between operating systems, graphics drivers and hardware, so the hash is characteristic of a machine class. The technique was described academically by Mowery and Shacham in Pixel Perfect: Fingerprinting Canvas in HTML5 (2012), and Englehardt and Narayanan's 2016 one-million-site measurement study found canvas fingerprinting scripts deployed on real sites.

Canvas output is highly stable on a given machine and hard to fake convincingly, because a plausible value has to look like something real hardware produces.

WebGL parameters and rendering

WebGL leaks in two ways. First, the renderer and vendor strings — often exposed through the debug renderer extension — name the graphics adapter and driver path directly. Second, the script reads dozens of numeric capability limits (maximum texture size, supported extensions, shader precision) and may render a 3D scene and hash the output, as with canvas.

The renderer string is one of the most useful consistency checks for a tracker: a graphics adapter that does not ship on the operating system the User-Agent claims is a direct contradiction.

Audio processing

An AudioContext (usually the offline variant, so nothing is played) generates a waveform, runs it through processing nodes such as a compressor, and hashes the resulting samples. Floating-point implementation details in the audio stack produce small, machine-specific differences. Englehardt and Narayanan reported this technique in the wild in the same 2016 study.

Font detection

Scripts cannot list installed fonts directly in most browsers, so they measure. Text is rendered in a candidate font with a fallback; if the width or height differs from the fallback alone, the font is installed. Repeating this over a few hundred candidates produces a font set. Each operating system ships a characteristic default set, and installed applications add more, so the list reveals both the OS and something about the machine's history.

Feature and API probing

Beyond named attributes, a script can test which APIs exist and how they behave: which codecs are supported, how many media input and output devices are reported, the state of permissions, the presence of vendor-specific objects, the precision of certain maths functions, the timing resolution available. Each result is a small signal on its own, and together they help distinguish browser engines and versions — including catching a browser that claims to be one engine while behaving like another.

WebRTC address discovery

WebRTC's connection setup gathers candidate network addresses. Depending on browser settings, it can reveal local network addresses or a public address different from the one the HTTP traffic arrives from. Strictly this is a leak rather than a fingerprint, but fingerprinting scripts routinely collect it, and a mismatch with the HTTP address undermines every other layer.

Passive techniques: what the connection reveals

HTTP header values and order

Every request carries headers — User-Agent, Accept, Accept-Language, Accept-Encoding, client hints. Beyond the values, the order headers appear in and their exact casing and formatting are characteristic of a browser engine and version. A request whose headers say one browser but arrive in another client's order is easy to spot server-side.

TLS handshake signatures

Before any HTTP is exchanged, the client's TLS ClientHello lists supported protocol versions, cipher suites, extensions and elliptic curves, in a specific order. Hashing that list gives a signature of the TLS implementation. JA3, open-sourced by Salesforce engineers in 2017, popularised the method; JA4, released by FoxIO in 2023, refines it to cope with browsers that now randomise extension order. Because the signature comes from the TLS library, not from page script, it cannot be changed from inside a browser profile — it reflects the actual engine making the connection.

HTTP/2 settings

HTTP/2 clients open a connection with SETTINGS values, window-update behaviour, stream priorities and pseudo-header order. Akamai researchers presented passive fingerprinting of HTTP/2 clients at Black Hat Europe in 2017, showing these values differ reliably between browsers and libraries.

TCP/IP stack traits

Lower still, the initial TTL, TCP window size and option ordering in the connection's first packets vary by operating system. Passive OS fingerprinting tools such as p0f have used this for years. If traffic passes through a proxy, these traits describe the proxy's machine rather than yours — which is itself a signal when it disagrees with the operating system the browser claims.

IP-derived attributes

The address gives geography, ASN, and whether the range belongs to a residential provider, a mobile carrier or a data centre. These are not browser properties, but fingerprinting systems routinely cross-reference them with the browser's timezone and languages. Our guides to static residential IPs and residential proxies vs VPNs cover this layer in more depth.

Behavioural signals sit alongside, not inside, the fingerprint

Typing cadence, pointer movement, scroll patterns and how quickly forms are completed are usually treated as a separate discipline — behavioural analysis or bot detection — rather than fingerprinting proper. They matter here because risk systems evaluate them together with the fingerprint: a perfectly coherent device fingerprint does nothing about behaviour that looks scripted.

How the pieces are combined

Two things follow from that table.

Stability is weighted, not just uniqueness. A tracker that recognises returning browsers cares about values that stay the same across visits; values that change with every browser update are weighted lower, and matching is often fuzzy so that one changed attribute does not break recognition. Peter Eckersley's 2010 EFF study How Unique Is Your Web Browser? showed both sides: most browsers in the sample were unique, and fingerprints changed often, yet a simple heuristic could still link many changed fingerprints back to the earlier ones.

Consistency is checked across families. Risk systems do not only ask "have I seen this device before?" They ask whether the active and passive layers describe the same machine. A profile whose canvas and WebGL say one platform, whose TLS and HTTP/2 signatures say another engine, and whose timezone disagrees with its IP is not rare — it is self-contradictory, and that is a stronger signal than uniqueness.

How browsers push back

Browser vendors counter fingerprinting with three broad strategies, each with a cost:

1. Uniformity — make every user look the same. Tor Browser takes this approach, standardising window sizes, fonts and many API results. It works only if many people share the exact configuration; any customisation makes a user stand out again.
2. Randomisation — add small noise to high-entropy outputs such as canvas and audio so they cannot be used as stable identifiers across sites. Brave documents this approach for its fingerprinting protections. The trade-off is that noise has to stay stable within a session and site, or it becomes its own signal.
3. Restriction — remove or coarsen APIs. Firefox's fingerprinting protections and Safari's Advanced Fingerprinting Protection limit or generalise what scripts can read, and User-Agent reduction in Chromium moves detail behind explicit requests.

None of these strategies touches the passive layer from inside the page. TLS, HTTP/2 and TCP/IP traits are set by the software and network actually making the connection.

What this means for an advertising operations environment

If you manage several ad accounts or client profiles, the practical lessons are about coherence rather than concealment:

• Derive settings from their source. Timezone and language should follow the exit IP's region, not be edited by hand per profile.
• Keep the claimed platform honest. A profile that claims an operating system and browser engine it is not actually running produces contradictions at the WebGL, font, TLS and HTTP/2 layers that no single setting fixes.
• Prefer stable values over changing ones. Values that change on every launch look less like a real machine than values that never change.
• Remember what fingerprinting does not cover. Payment instruments, phone numbers, recovery contacts and behaviour link accounts at layers the browser never sees — see how platforms link ad accounts.

None of this changes what an ad platform's policies allow. Isolated, coherent environments are for keeping legitimately separate accounts, clients and team members apart — not for getting around a platform's rules. For the tooling itself, our overview of fingerprint and anti-detect browsers explains what the category does and does not solve, and the cross-border ad environment setup guide covers the order in which the layers should be assembled.

FAQ

What is the most common browser fingerprinting technique?

Attribute probing — reading the User-Agent, screen, timezone and language — is the most common because it is cheap and needs no special API. Canvas, WebGL and font detection are the most common high-entropy techniques layered on top of it.

Does private or incognito mode stop browser fingerprinting?

No. Private mode clears cookies and storage when the window closes, but the device's rendering, fonts, hardware and network traits stay the same, so the fingerprint is largely unchanged.

Does a VPN or proxy prevent fingerprinting?

It changes the IP-derived attributes only. Active techniques still read the same browser and device, and a timezone or language that no longer matches the new IP can make the browser more distinctive, not less.

Which fingerprinting techniques cannot be changed from inside a browser profile?

Passive network signatures — the TLS handshake, HTTP/2 settings and TCP/IP traits — are produced by the software and network stack making the connection, so settings inside a browser profile do not alter them.