Anatomy of a browser fingerprint

Browser fingerprinting is the practice of identifying or classifying a visitor from the signals their browser and connection give off, without cookies. Anti-bot systems use it to decide whether a request comes from a real browser or a script, by checking that every signal layer tells the same story.

The stack at a glance

flowchart TB
    accTitle: Browser fingerprint layers
    accDescr: Four signal layers, network, protocol, runtime and behavior, feed one consistency check that passes, challenges or blocks the request.
    subgraph L1[1. Network]
        A1[IP and ASN]
        A2[TCP options, TTL]
    end
    subgraph L2[2. Protocol]
        B1[TLS ClientHello → JA4]
        B2[HTTP/2 SETTINGS, header order]
    end
    subgraph L3[3. Runtime]
        C1[navigator, screen, timezone]
        C2[canvas, WebGL, audio, fonts]
        C3[integrity: patched functions]
    end
    subgraph L4[4. Behavior]
        D1[pointer paths, scroll, keys]
    end
    L1 --> L2 --> L3 --> L4
    L1 & L2 & L3 & L4 --> S{{Consistency check<br/>across layers}}
    S -->|agree| P[pass]
    S -->|undecided| C[challenge]
    S -->|contradict| X[block]
    class L1 blue
    class L2 violet
    class L3 teal
    class L4 amber
    class S key
    class P ok
    class C warn
    class X bad

Each layer is read at a different moment: the network before the handshake, the protocol during it, the runtime after JavaScript loads, and behavior for the life of the session. The verdict comes from comparing them, not from any one of them.

The four layers

Layer 1, network. Before any HTTP, the server sees your IP address, its autonomous system (datacenter, residential ISP, or mobile carrier), the TCP options and initial window size, and TTL. These hint at the operating system and the hosting type. A datacenter ASN already costs you points.

Layer 2, protocol. The TLS ClientHello announces cipher suites, extensions and their order, supported curves and ALPN values. HTTP/2 adds the SETTINGS frame, window update values and pseudo-header order. Together these identify the HTTP client library with high precision. Chrome, Firefox, Safari, Go's net/http, Python requests and curl all look different here, and no header can hide it.

Layer 3, runtime. Once JavaScript runs, the client script reads hundreds of properties: navigator fields, screen geometry, time zone, languages, installed fonts, media codecs, WebGL vendor and renderer strings, canvas and audio rendering hashes, and the shape of the window object itself. It also checks what is missing or inconsistent: a Chrome user agent with no chrome object, a desktop screen reporting touch points, a timezone that disagrees with the IP's country.

Layer 4, behavior. Mouse movement, scroll cadence, focus and visibility events, keystroke timing, and the time between page load and first interaction. Covered in its own post.

Why consistency beats uniqueness

A common misconception is that the goal of a fingerprint is to identify one user across sessions. Tracking vendors want that. Anti-bot vendors want something simpler: a risk score.

They compare each layer against the population of real browsers that claim the same identity. If a visitor says "Chrome 130 on Windows" at layer 3 but its TLS fingerprint matches Go at layer 2, the score is decided. If every layer agrees but the IP is a known proxy range, the request may still pass with a challenge.

This is why "set a realistic user agent" has been useless advice for years. The user agent is the cheapest signal to fake and therefore the least trusted. Since Chrome reduced the UA string, the detail moved to User-Agent Client Hints (Sec-CH-UA, Sec-CH-UA-Platform, the full-version list on request) and to navigator.userAgentData. A UA string that claims Chrome 150 on Windows next to Client Hints that say Linux is the same contradiction at a different layer, and 2026 detection write-ups list a single UA profile without matching hints among the patches that stopped working in 2024 to 2025.

Where the entropy is

Not all signals are equal. Roughly, in order of distinguishing power for a modern browser:

1. Canvas and WebGL rendering hashes (GPU, driver, OS font rasterizer).
2. Font enumeration via measured text widths.
3. Audio context output hash.
4. Screen and window geometry combined with device pixel ratio.
5. Language, timezone and locale set.
6. Everything else, including the user agent.

The top three are hardware and driver dependent, which is why headless browsers in a datacenter cluster look alike: same virtual GPU, same fonts, same software renderer, thousands of times.

Demonstration: print your own layers

Open any page, paste this in the DevTools console, and read the output. It covers the runtime layer only; the protocol layer is shown in the next post, on TLS and HTTP/2 fingerprints.

(async () => {
  const c = document.createElement('canvas');
  const g = c.getContext('webgl') || c.getContext('experimental-webgl');
  const dbg = g && g.getExtension('WEBGL_debug_renderer_info');
  const ctx2d = c.getContext('2d');
  ctx2d.textBaseline = 'top'; ctx2d.font = '14px Arial';
  ctx2d.fillText('fingerprint \u{1F50D}', 2, 2);
  const canvasHash = [...new Uint8Array(await crypto.subtle.digest('SHA-256',
    new TextEncoder().encode(c.toDataURL())))].slice(0, 8)
    .map(b => b.toString(16).padStart(2, '0')).join('');
  console.table({
    userAgent: navigator.userAgent,
    platform: navigator.platform,
    hardwareConcurrency: navigator.hardwareConcurrency,
    deviceMemory: navigator.deviceMemory,
    languages: navigator.languages.join(','),
    timezone: Intl.DateTimeFormat().resolvedOptions().timeZone,
    screen: `${screen.width}x${screen.height}@${devicePixelRatio}`,
    outer: `${outerWidth}x${outerHeight}`,
    touchPoints: navigator.maxTouchPoints,
    webdriver: navigator.webdriver,
    webglVendor: dbg ? g.getParameter(dbg.UNMASKED_VENDOR_WEBGL) : 'n/a',
    webglRenderer: dbg ? g.getParameter(dbg.UNMASKED_RENDERER_WEBGL) : 'n/a',
    canvasHash,
  });
})();

Expected output on a real laptop: a hardware renderer string such as an Apple, NVIDIA, AMD or Intel GPU, webdriver: false, and outer dimensions slightly larger than inner ones because of the browser chrome.

Expected output in headless Chrome without a GPU: a software renderer (SwiftShader or ANGLE over llvmpipe), webdriver: true when driven through automation, and outerWidth of 0 in older builds. Run the same snippet in both and diff the tables. That diff is the detection surface at layer 3.

Frequently asked questions

What is a browser fingerprint?

A browser fingerprint is the combined set of signals a site can read from a visitor: IP and network data, the TLS handshake, JavaScript-visible properties such as screen, fonts, canvas and WebGL output, and behavior. Together they describe a device well enough to recognize it, or to tell a real browser from automation.

Can changing the user agent avoid fingerprinting?

No. The user agent is the cheapest signal to fake and the least trusted. Since Chrome's user-agent reduction the detail lives in Client Hints, and a user agent that contradicts the TLS fingerprint, Client Hints or runtime properties makes detection easier, not harder.

Which fingerprint signals carry the most information?

Canvas and WebGL rendering hashes, font measurements and the audio context hash carry the most, because they depend on the GPU, the driver and the operating system. Screen geometry, language and timezone come next. The user agent carries very little.

How do anti-bot systems use fingerprints?

They compare each layer with real browsers that claim the same identity and score the contradictions. Hard rules block impossible combinations, a statistical model scores the rest, and session context such as IP geography and behavior moves the score until the request passes, gets a challenge, or is blocked.