How Browser Fingerprinting Works

Passive Fingerprinting: What Your Browser Reveals Automatically

Before any JavaScript runs, your browser has already disclosed a significant amount of identifying information through the HTTP request itself. Every request includes headers that reveal your browser type, version, operating system, preferred languages, and supported content types. This is called passive fingerprinting because the server collects the data without executing any client-side code.

The User-Agent header is the most obvious signal. It contains the browser name, version number, operating system, and sometimes the device model. A typical Chrome User-Agent on Windows looks something like Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36. While User-Agent strings are easy to spoof, most passive fingerprinting systems use them as one input among many rather than relying on them exclusively.

The Accept-Language header reveals your language preferences, including dialect codes and quality weights. A user in Germany might send de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7, while someone in Japan sends a completely different set. The specific languages, their ordering, and the quality values all contribute to the fingerprint.

The order and presence of HTTP headers varies between browsers. Chrome, Firefox, Safari, and Edge each send headers in a slightly different sequence and include different optional headers. This ordering is determined by the browser's source code and cannot be changed by the user, making it a reliable, if low-entropy, signal.

TLS fingerprinting operates during the connection handshake, before any HTTP data is exchanged. When your browser initiates a TLS connection, it sends a Client Hello message listing its supported cipher suites, TLS extensions, elliptic curves, and signature algorithms. The JA3 fingerprinting method hashes these parameters into a short string that identifies the client software. Different browsers, browser versions, and HTTP client libraries each produce distinct JA3 hashes. For example, headless Chrome controlled by Puppeteer has a different JA3 hash than the same version of Chrome run manually, because the automation framework subtly changes the TLS configuration. The newer JA4 method extends this approach with additional granularity.

HTTP/2 fingerprinting adds another layer. When a browser establishes an HTTP/2 connection, it sends a SETTINGS frame declaring parameters like maximum concurrent streams, initial window size, header table size, and whether server push is enabled. It also sends WINDOW_UPDATE frames and establishes stream priorities using a scheme specific to its implementation. Chrome, Firefox, and Safari each use different HTTP/2 parameters and priority algorithms, creating a network-level fingerprint that operates independently of any JavaScript.

Active Fingerprinting: JavaScript-Based Collection

Active fingerprinting uses JavaScript to probe the browser and device through Web APIs. This is where most of the fingerprint's entropy comes from, because JavaScript provides access to hardware characteristics, rendering behavior, and system configuration that HTTP headers cannot reveal.

The collection process typically begins when a fingerprinting script loads on the page, either embedded directly in the HTML, loaded from a third-party service, or injected by a CDN's bot detection layer. The script executes a series of probes, each targeting a different API or browser feature, and collects the results into a data structure that gets sent to the server or hashed client-side into a visitor identifier.

Navigator API probing is the simplest form of active collection. The script reads properties from the navigator object: userAgent, platform, language, languages, hardwareConcurrency (CPU core count), deviceMemory (available RAM in gigabytes), maxTouchPoints, cookieEnabled, doNotTrack, and webdriver. It also reads screen properties: screen.width, screen.height, screen.colorDepth, screen.availWidth, screen.availHeight, and window.devicePixelRatio. Each property contributes a few bits of entropy, and collectively they establish the basic profile of the device.

Canvas fingerprinting is the highest-entropy JavaScript-based technique. The script creates a hidden <canvas> element, draws a complex scene that includes text in specific fonts, geometric shapes with gradients, and sometimes emoji characters. It then calls canvas.toDataURL() to extract the rendered image as a base64-encoded PNG and hashes the result. Because different GPUs, graphics drivers, operating systems, and font rendering engines produce slightly different pixel outputs for identical drawing instructions, the hash is nearly unique per device. The differences come from anti-aliasing algorithms, sub-pixel rendering, font hinting, color space handling, and floating-point arithmetic in the GPU's shader pipeline.

WebGL fingerprinting takes rendering-based identification into the 3D graphics pipeline. At the basic level, the script queries the WebGL context for the WEBGL_debug_renderer_info extension, which exposes the GPU vendor string (like "Google Inc. (NVIDIA)") and the renderer string (like "ANGLE (NVIDIA, NVIDIA GeForce RTX 4070 Direct3D11 vs_5_0 ps_5_0, D3D11)"). At a deeper level, the script renders a 3D scene with specific lighting, textures, and shading, then reads back the pixel data and hashes it. WebGL also exposes supported extensions, maximum texture dimensions, shader precision ranges, and other parameters that vary across GPU and driver combinations.

AudioContext fingerprinting exploits the Web Audio API. The script creates an OfflineAudioContext, connects an oscillator node through a dynamics compressor to the audio destination, renders a short buffer (typically 0.5 seconds), and reads back the floating-point audio samples. The sample values differ at the sixth or seventh decimal place across different audio hardware and drivers, providing a consistent but device-specific signal. Audio fingerprinting is harder to spoof than canvas or WebGL fingerprinting because it operates on a completely different hardware subsystem.

Font detection works by measuring text rendering dimensions. The script creates hidden <span> elements containing a test string, applies each candidate font with a known fallback, and measures the resulting element width and height. If the dimensions differ from the fallback-only rendering, the font is installed. Testing 200-500 common fonts produces a list that is highly distinctive, especially on Windows where users frequently install additional font packages through Office, Adobe products, and other software.

Plugin and MIME type enumeration was historically a major fingerprinting vector through navigator.plugins and navigator.mimeTypes. Modern browsers have largely frozen or removed these APIs, but they still contribute to fingerprinting on older browser versions and in some enterprise environments.

How the Fingerprint Is Assembled

Once all probes have completed, the fingerprinting library assembles the collected data into a structured result. Some libraries, like the open-source FingerprintJS, hash all attributes together into a single visitor identifier using a deterministic hashing algorithm like MurmurHash3. Others, like Fingerprint Pro and commercial anti-bot solutions, send the raw attribute data to a server-side processing pipeline that uses machine learning to compute the identifier and assess confidence.

The server-side approach is more powerful because it can compare the incoming fingerprint against a database of known configurations, detect statistical anomalies, identify spoofing attempts, and assign a confidence score. For example, if a browser claims to be Chrome 126 on Windows 11 but its canvas hash matches a known Linux rendering profile, the server can flag the inconsistency even though the individual attributes look plausible in isolation.

Fingerprint stability is an important consideration. Browser updates, driver updates, font installations, and screen resolution changes all alter the fingerprint. A good fingerprinting system uses fuzzy matching rather than exact hash comparison, allowing a certain number of attributes to change between visits while still identifying the same device. Commercial systems report identification accuracy above 99.5% by using this probabilistic approach.

The entire collection process typically completes in under 100 milliseconds, fast enough to run during page load without any perceptible delay. The fingerprinting code often runs before the page's main content is visible, meaning the server has already identified the visitor before the user sees anything on screen.

Evading Fingerprint Collection

Understanding how fingerprinting works is the foundation for evading it, whether for privacy or for automation purposes. The three primary evasion strategies are blocking, randomizing, and spoofing.

Blocking means preventing the fingerprinting script from running at all, either by disabling JavaScript (which breaks most modern websites), using browser extensions that block known fingerprinting scripts, or using browsers like Tor that restrict API access. The downside is that blocking often creates a distinctive fingerprint of its own, because a browser with Canvas API access blocked is itself unusual.

Randomizing means returning different values each time the fingerprinting script runs, so the computed fingerprint changes on every page load. Brave browser does this for Canvas and WebGL fingerprinting by adding imperceptible random noise to the rendered output. This prevents cross-session tracking but does not prevent per-session identification.

Spoofing means returning specific, chosen values that mimic a real browser on real hardware. This is the approach antidetect browsers take, creating complete, internally consistent profiles where every attribute matches what the claimed configuration would actually produce. Spoofing is the most effective approach for automation but also the most complex, because any inconsistency between spoofed attributes can reveal the deception.