Browser Detection Signals Glossary 2026: ClientRects to TLS Tickets

Canvas hash, WebGL renderer, Client Hints, cookies: these are the signals every fingerprinting guide covers, and a profile can look perfectly consistent on all of them while another signal quietly disagrees. ClientRects geometry is a good example. Two profiles on the same machine can share identical sub-pixel layout values even when everything else differs.

That's the problem with fingerprinting glossaries: they're stuck in 2022 or 2023. Canvas fingerprinting, WebGL renderer strings and user-agent parsing are covered in every guide you'll find. The signals that shipped after those guides were written are much harder to find, and many of them are documented only in academic papers written for researchers.

So here is a plainer version. Eleven signals that post-date most existing glossaries, explained for people who run browser profiles, test their own sites or care about privacy. If you've already read the multi-account browser myths guide, this picks up where it left off.

See what your own browser reports first. There is a public viewer at justbrowser.app/fingerprint-checker: client-side, no signup. It compares WebRTC candidates against your public IP, and checks whether the IP's location agrees with your browser's timezone. Worth running before you read the rest of this, so the signals below have your own values attached to them.

1. ClientRects Fingerprinting

What it is: A technique that calls getBoundingClientRect() and getClientRects() on rendered DOM elements, then measures the precise pixel dimensions returned. Different browsers, OS rendering engines, font configurations, and zoom levels produce subtly different bounding box values.

Why it matters: High-entropy and stable per machine. Unlike canvas (where you hash pixel data), ClientRects returns geometric coordinates influenced by dozens of rendering variables — font rendering, DPI scaling, browser zoom, OS text smoothing. A 400x100 div on one machine might report 400.0000 × 100.0000, and on another 400.0234 × 99.9891. Those sub-pixel differences are consistent per machine and vary across users.

In practice: A browser that changes canvas, WebGL and fonts but leaves ClientRects at native values gives every profile on one machine identical geometry, even if every other parameter differs. A tracker that reads this signal can tie those browsing identities back to one machine, which is exactly what a privacy-minded user wants to know about.

To test, open console and run:

const el = document.createElement('div');
el.style.cssText = 'position:absolute;width:400px;height:100px;font-family:Arial';
el.textContent = 'ClientRects test';
document.body.appendChild(el);
console.log(el.getBoundingClientRect());
document.body.removeChild(el);

Compare values across profiles. If they match exactly, the profiles share a rendering environment.

2. WebAssembly (WASM) Feature Detection

What it is: Sites probe which WebAssembly features your browser supports — SIMD, threads, exception handling, bulk memory operations. The combination of supported features becomes a fingerprint.

Why it matters: WASM feature sets vary by browser version, OS, and hardware. A browser that reports a given Chrome release on Windows should support the WASM features that release ships. If the actual feature set doesn't match, the browser is reporting contradictory information.

It can look too niche to matter, but a Firefox user agent paired with the WASM support of a Chromium V8 engine is an obvious contradiction.

In practice: WASM fingerprinting is still emerging. Sites test features like WebAssembly.validate() on known-invalid modules to probe capability boundaries. Results reveal browser and platform combinations with moderate entropy.

Test your profile:

const features = {
  threads: typeof SharedArrayBuffer !== 'undefined',
  simd: (() => {
    try {
      return WebAssembly.validate(new Uint8Array([0,97,115,109,1,0,0,0,1,5,1,96,0,1,123,3,2,1,0,10,10,1,8,0,65,0,253,15,253,98,11]));
    } catch { return false; }
  })()
};
console.log(features);

Cross-reference against what the browser version in the profile should report.

3. Network Information API

What it is: The navigator.connection object exposes network characteristics — effectiveType (4g, 3g, 2g, slow-2g), downlink (bandwidth in Mbps), rtt (round-trip time in ms), and saveData (data saver mode boolean).

Why it matters: The values are coarse on purpose. Chrome rounds rtt and downlink and caps effectiveType at 4g, so a fast office line and a good mobile connection can report the same thing. On its own the signal carries little entropy. Its value to a site is as a cross-check: a browser that describes itself as a phone in São Paulo, on an IP address that belongs to a hosting provider in Virginia, tells an inconsistent story.

In practice: Sites can compare Network Info with IP geolocation, the ASN type and the device the browser reports. For a desktop browser on broadband, expect 4g and rounded values.

Check your profile:

if (navigator.connection) {
  console.log({
    effectiveType: navigator.connection.effectiveType,
    downlink: navigator.connection.downlink,
    rtt: navigator.connection.rtt,
    saveData: navigator.connection.saveData
  });
}

Expect coarse, rounded numbers. The interesting question is whether they fit the connection the IP address describes.

4. TLS Session Tickets and Resumption

What it is: TLS session tickets allow clients to resume encrypted connections without a full handshake. The ticket itself — its format, lifetime, and reuse patterns — reveals information about your browser and network stack.

Why it matters: Session ticket behavior varies by browser, OS, and TLS library version. Some browsers rotate tickets aggressively; others reuse them. The pattern of ticket presentation across requests can fingerprint your connection independently of JA3/JA4 signatures.

In practice: TLS fingerprinting has moved beyond static cipher suite ordering. Session resumption behavior adds a temporal dimension — how often you reuse tickets, whether you support 0-RTT resumption, how your browser handles ticket rotation.

This is server-side fingerprinting, so you can't inspect it from JavaScript. You can only see it by capturing your own traffic with Wireshark and comparing against expected patterns, which makes it hard to test.

The JA4 TLS fingerprinting guide covers the static signatures. Session ticket behavior is the next layer.

5. WebGPU Adapter Enumeration

What it is: The navigator.gpu.requestAdapter() call returns structured information about your GPU — vendor and architecture strings, plus dozens of capability limits. It's a completely different API surface than WebGL's debug extensions.

Why it matters: WebGPU exposes GPU identity through a second, independent route. The adapter info includes vendor and architecture strings (for example "nvidia" and "ampere"), and the adapter's capability limits add more detail. Chrome buckets those limits to reduce how much they reveal, but the vendor and architecture still describe the hardware.

In practice: WebGL and WebGPU are separate API paths, and a browser can change one without the other. A browser reporting "Intel UHD 620" through WebGL while reporting "NVIDIA GeForce RTX 4070" through WebGPU describes impossible hardware, and the contradiction is trivial to see.

Query both APIs and compare:

// WebGL
const canvas = document.createElement('canvas');
const gl = canvas.getContext('webgl');
const debug = gl.getExtension('WEBGL_debug_renderer_info');
console.log('WebGL:', gl.getParameter(debug.UNMASKED_RENDERER_WEBGL));

// WebGPU
const adapter = await navigator.gpu?.requestAdapter();
console.log('WebGPU:', adapter?.info);

If these don't tell the same story, the browser is reporting contradictory hardware. The WebGL fingerprinting deep-dive walks through the WebGL side in full.

6. User-Agent Client Hints (UA-CH) Extended Set

What it is: HTTP headers that replaced the user-agent string for structured browser identification. Beyond the basic Sec-CH-UA, sites can request extended hints: Sec-CH-UA-Full-Version-List, Sec-CH-UA-Platform-Version, Sec-CH-UA-Bitness, Sec-CH-UA-Form-Factor, Sec-CH-UA-WoW64.

Why it matters: Client Hints provide cross-checkable claims. A browser on Windows 11 reports a specific platform version range, and its full version list has to match the Chrome release it claims. Inconsistencies between Client Hints and navigator properties are an immediate sign that something has been overridden.

In practice: Tools that only change the user-agent string often miss the extended hints. Sites can request the full set and compare. Sec-CH-UA-Bitness (32 vs 64-bit) has to agree with the platform the rest of the browser describes, and Sec-CH-UA-WoW64 only means anything on Windows.

The list of hints has grown over time, and each new one is another value that has to agree with the rest. Hardware-side signals that hints and navigator values must agree with are covered in the audio, font and hardware fingerprinting guide.

7. Permissions API State

What it is: The navigator.permissions.query() API returns the state of browser permissions — granted, denied, or prompt — for capabilities like notifications, geolocation, camera, microphone.

Why it matters: Permission states persist across sessions and accumulate into a fingerprint. A new browser profile has every permission in "prompt" state. A browser in everyday use shows a mix: granted notifications on some sites, denied camera access on others, geolocation granted for maps. The pattern reflects how the browser has been used.

In practice: Permission states are per-profile, so each profile builds up its own set as you work in it, and a profile you have just created naturally shows all "prompt".

Check your permission states:

const perms = ['notifications', 'geolocation', 'camera', 'microphone'];
for (const name of perms) {
  const status = await navigator.permissions.query({ name });
  console.log(name, status.state);
}

All "prompt" simply means no permission decisions have been made in that profile yet.

8. MediaDevices Enumeration

What it is: The navigator.mediaDevices.enumerateDevices() call lists available audio and video input/output devices — microphones, cameras, speakers, virtual devices.

Why it matters: Device enumeration produces highly identifying combinations. Most laptops have one camera and one microphone. Desktop setups vary. Virtual machines and some browsers expose unusual device lists — zero devices, or many virtual ones — and once a site has camera or microphone access, device names that don't fit the hardware being reported.

In practice: Until a site is granted camera or microphone access it sees device kinds and counts, not names, but that is still informative: a browser describing a MacBook should list devices consistent with that hardware. Virtual audio drivers on the host machine, such as a music-production audio router, show up in every browser on that machine, which lets a tracker tie them together.

9. Speech Synthesis Voices

What it is: The speechSynthesis.getVoices() API returns available text-to-speech voices, which vary by OS, language packs, and browser.

Why it matters: Voice lists are OS-specific with high fidelity. Windows 11 has different default voices than Windows 10. macOS has voices Windows doesn't. The list of available voices cross-validates OS and locale claims.

In practice: A profile set to Windows 11 US English should have specific Microsoft voices. A macOS profile that returns Windows voices is an obvious mismatch.

This signal matters more on desktop than on mobile, where voice lists are less reliably queried. For what multi-account browsers do and don't change, see the multi-account browser myths guide.

10. Math and Error Stack Fingerprinting

What it is: Subtle differences in how JavaScript engines handle math operations (trigonometric functions, random number generation edge cases) and format error stack traces.

Why it matters: Math.tan(-1e300) returns different values on different JavaScript engines. Stack trace formatting differs between Chrome and Firefox, and between V8 versions. These signals reveal browser engine identity independently of user-agent strings.

In practice: A profile that reports Firefox but returns V8-style stack traces is inconsistent. Math fingerprinting is lower entropy than canvas or WebGL, but it's another cross-validation layer.

This is why a Chromium-based browser should present a Chromium identity: engine behaviour can't be swapped by changing a user-agent string. For how one large platform combines signals like these with account data, see the Facebook fingerprinting and Business Manager guide.

11. ECH (Encrypted Client Hello) and TLS 1.3 Variations

What it is: Encrypted Client Hello hides the SNI (Server Name Indication) during TLS handshakes, but ECH support varies by browser, OS, and network configuration. The presence or absence of ECH — and how it's negotiated — becomes a fingerprint signal.

Why it matters: ECH is rolling out unevenly. Some browsers support it, some don't. Some networks block ECH-enabled connections. Whether your browser attempts ECH, falls back gracefully, or fails entirely reveals configuration details.

In practice: This is nascent but worth tracking. Chrome and Firefox now enable ECH by default, and as server support grows, so does this surface. A browser that reports a current Chrome release should behave like one when ECH is available.

It is not a pressing issue yet, but it is worth watching.

Honorable Mentions

Storage Quota Fingerprinting: Sites probe navigator.storage.estimate() to see available disk space. Values vary by device and reveal storage characteristics. Low entropy alone but useful for cross-validation.

Gamepad API: navigator.getGamepads() returns connected controllers. Unusual in multi-profile contexts, but VM environments sometimes expose virtual gamepads that don't exist on the hardware being reported.

Bluetooth API State: Whether navigator.bluetooth exists and what permissions it has can fingerprint browser configuration. Mostly relevant for distinguishing mobile from desktop profiles.

Quick Verdict

If you take one thing from this glossary: the signals that matter in 2026 aren't the ones in 2023 guides. Canvas and WebGL are table stakes. ClientRects, WebGPU, the extended Client Hints and TLS session behavior are where inconsistencies show up today.

If you run a site, these are the signals worth knowing about when you read your own fraud or analytics data. If you care about privacy, they are what any page can collect without asking. If you manage browser profiles for a team, run the queries in each one and fix anything that contradicts the rest, so each profile reports one coherent identity. It is tedious, and running the queries yourself is the most reliable way to do it.

For protection on the ad spend side while you run campaigns, ClickzProtect monitors click quality and blocks bot traffic before it drains your budget. For privacy-first analytics that doesn't add fingerprinting surface, JustAnalytics handles attribution without feeding data back to platforms.

Fingerprinting techniques keep moving faster than documentation, so it pays to re-run these checks from time to time.

Frequently Asked Questions

Why do 2026 fingerprinting glossaries need different terms than 2024 guides?

Because the signals moved. Older glossaries cover canvas, WebGL and the user-agent string, which every guide now explains. Newer APIs such as WebGPU (in stable Chrome since 2023), the extended Client Hints and TLS-layer behaviour add signals those guides never mention, and they are where a browser's reported identity and its real behaviour can disagree.

Which emerging signal causes the most consistency problems in 2026?

ClientRects and WebGPU mismatches are the quiet ones. Canvas and WebGL get most of the attention, while ClientRects geometry is easy to overlook, and WebGPU exposes GPU identity through a completely different API path than WebGL. A browser reporting Intel UHD through WebGL but RTX 3070 through WebGPU describes impossible hardware, and any script that queries both sees the contradiction.

Are these signals actually used by major platforms or just fingerprinting vendors?

Vendors such as FingerprintJS, HUMAN (which merged with PerimeterX) and DataDome don't publish their full signal lists, and large platforms run their own in-house systems. Treat any claim about exactly which vendor reads which signal as a guess. The safe assumption is that any API a page can call can be read.

How do I check what my own browser profiles report for these signals?

Run the JavaScript snippets in each section of this glossary in the profile or browser you want to inspect. Check whether ClientRects returns the same values across restarts, whether WebGPU adapter info matches the WebGL renderer, and whether Network Info fits the connection you are on. Public fingerprint viewers cover some of these checks, but not all, so running the queries yourself is the most reliable way to see what a browser reports.

---

Try JustBrowser

A multi-account browser for teams, built on a custom Chromium engine — not extension-based. Native C++ engine patches at the canvas / WebGL / audio / font / screen layer provide 40+ identity parameters, and each profile keeps its own cookies, storage and proxy. Local REST API + CDP for Playwright, Puppeteer, Selenium. $9.99/month or $99.99/year. 7-day free trial, card required — cancel any time in the seven days and you are not charged. Unlimited profiles.

Get started → · How it differs from Multilogin / GoLogin / AdsPower