Browser Detection Signals Glossary 2026: ClientRects to TLS Tickets

Last month a colleague forwarded me a ban notice from a client's Facebook Business Manager. Clean canvas hash. WebGL matched the profile config. Client Hints aligned. Cookie history looked organic. Every browser detection signal test we knew how to run came back green.

The linking signal, according to the debrief? ClientRects geometry.

I had to Google it. Embarrassing. I've been running multi-account operations for three years and I'd never once checked ClientRects values across my profiles.

That's the problem with fingerprinting glossaries — they're stuck in 2022 or 2023. Canvas fingerprinting, WebGL renderer strings, user-agent parsing — sure, beaten to death in every guide you'll find. But the detection signals that actually catch profiles in 2026? The ones that shipped after those guides were written? Good luck. I spent two hours digging through academic papers before finding anything useful, and honestly, half of it was written for researchers who've never had to explain to a client why their "clean" profile got nuked.

So here's my attempt to fix that. Eleven signals that post-date most existing glossaries, explained for people who run accounts — not researchers writing papers. Fair warning: I'm still learning some of this myself. If you've already got the original antidetect glossary memorized, this picks up where it left off.

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 hard to spoof. 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 your machine might report 400.0000 × 100.0000. On mine? 400.0234 × 99.9891. Those sub-pixel differences are consistent per machine and vary across users.

The operational angle: Most antidetect browsers don't touch ClientRects. They spoof canvas hashes, WebGL renderers, fonts — but let ClientRects report native values. Two profiles on the same machine share identical ClientRects geometry even if every other fingerprint diverges. Platforms that check this signal link accounts instantly.

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? You've got a problem.

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 profile claiming Chrome 120 on Windows should support specific WASM features. If the actual feature set doesn't match? The profile's identity story falls apart.

I'll admit I underestimated this one at first. Seemed too niche. But then I watched a detection vendor demo where they caught a spoofed Firefox profile because its WASM support screamed "Chromium V8 engine."

The operational angle: WASM fingerprinting is still emerging, but it's growing fast. 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 your spoofed browser version 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: Network Info should match your proxy and device profile. A "mobile" profile on 4G using a datacenter proxy with 1ms RTT and 100 Mbps downlink? Impossible. Real mobile connections have higher latency and variable bandwidth. You can't claim to be browsing from a phone in São Paulo while your connection looks like a server rack in Virginia.

The operational angle: Platforms cross-check Network Info against IP geolocation, ASN type, and device claims. Spoofing this requires knowing plausible values for your target device and network type — which, frankly, most documentation doesn't cover. I've had to run real devices on real networks just to collect baseline 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
  });
}

Does a datacenter connection claiming "4g" with 2ms RTT make sense? No. It doesn't.

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.

The operational angle: 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.

Here's the frustrating part: this is server-side fingerprinting. You can't inspect it from JavaScript. You're essentially blind to it unless you capture your own traffic with Wireshark and compare against expected patterns. I hate signals I can't easily 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, architecture, device description, and dozens of capability limits. It's a completely different API surface than WebGL's debug extensions.

Why it matters: WebGPU exposes GPU identity more explicitly than WebGL ever did. The adapter info includes architecture ("ampere", "rdna3", "xe"), specific device names, and numeric limits that identify GPU models down to driver versions.

The operational angle: This is where I think half the industry is about to get burned. Most antidetect browsers spoof WebGL but not WebGPU. A profile claiming "Intel UHD 620" through WebGL while reporting "NVIDIA GeForce RTX 4070" through WebGPU has impossible hardware. The contradiction is trivially detectable.

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, your profile is lying. The WebGPU fingerprinting deep-dive walks through the full detection surface.

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 profile claiming Windows 11 should report a specific platform version range. Claiming Chrome 126 means the full version list must include the right builds. Inconsistencies between Client Hints and navigator properties? Immediate spoofing signals.

The operational angle: Early antidetect tools spoofed the basic hints but missed the extended set. Sites now request the full hint repertoire and compare. Sec-CH-UA-Bitness (32 vs 64-bit) must match hardware concurrency expectations. Sec-CH-UA-WoW64 matters for Windows profiles.

The annoying thing here is that the spec keeps expanding. Every few months there's a new hint header, and every few months there's another consistency check that could trip you up. The Client Hints fingerprinting guide breaks down current consistency requirements, but honestly, I expect it to need an update by Q3.

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 a fingerprint. A fresh profile has all permissions in "prompt" state. A real user's profile shows a mix: granted notifications on some sites, denied camera access on others, geolocation granted for maps. The pattern reveals whether a profile is actually aged or freshly created.

The operational angle: Cookie warm-up and profile aging partially address this, but many operators forget to age permission states. A six-month-old profile with zero permission decisions? Suspicious. Realistic aging includes granting and denying permissions on common sites — and yes, that's tedious manual work that most people skip.

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"? That's a newborn profile, regardless of what the cookie history claims.

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 antidetect tools often expose unusual device lists — zero devices, many virtual devices, or device names that don't exist on claimed hardware.

The operational angle: A profile claiming to be a MacBook Pro should enumerate devices consistent with that hardware. No camera on a claimed laptop? Suspicious. Virtual audio drivers that only exist on the operator's real machine? Linking signal.

I've made this mistake myself — had my DAW's virtual audio router leaking through on every profile. Took me three weeks to figure out why accounts kept getting linked. The MediaDevices fingerprinting guide covers device list normalization.

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.

The operational angle: A profile claiming Windows 11 US English should have specific Microsoft voices. Claiming macOS but returning Windows voices? Instant detection.

This signal matters more for desktop profiles than mobile. Most mobile antidetect work involves emulation anyway, where voice lists are less reliably queried. The speech synthesis fingerprinting breakdown walks through OS-specific voice lists.

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 claims.

The operational angle: A profile claiming Firefox but returning V8-style stack traces is lying. Math fingerprinting is lower entropy than canvas or WebGL, but it's another cross-validation layer.

Honestly, this one's hard to mess up if you're using a proper antidetect browser rather than a wrapper. But if you're doing something weird with browser automation that swaps user-agents without swapping engines... yeah, this will catch you. The math and error stack analysis details the specific checks.

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.

The operational angle: This is nascent but worth tracking. As ECH adoption grows (Chrome enabled it by default in mid-2024), the fingerprint surface expands. A profile claiming Chrome 126 should behave correctly when ECH is available.

I'm not losing sleep over this one yet, but I'm watching it. The ECH and TLS 1.3 fingerprinting analysis covers the emerging detection landscape.

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-account contexts, but VM environments sometimes expose virtual gamepads that don't exist on claimed hardware. (Yes, really. I've seen it.)

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 catch profiles in 2026 aren't the ones in 2023 guides. Canvas and WebGL are table stakes. ClientRects, WebGPU, Network Info, and TLS session behavior are where operators get burned today.

Test your profiles against every signal in this list. If you find inconsistencies, fix them before platforms find them for you. And yeah, it's tedious. I wish I had better advice than "run these tests manually across every profile." But that's where we are.

For protection on the ad spend side while you're running accounts, 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. Both integrate cleanly with multi-account setups where detection signals matter.

The detection arms race doesn't pause for documentation to catch up. Neither should you.

Frequently Asked Questions

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

Detection evolved faster than documentation. ClientRects fingerprinting went from academic paper to production detector between 2024 and 2025. WebGPU shipped to stable Chrome in 2023 but detection services only started querying it in late 2025. TLS session ticket fingerprinting became viable after JA4 gained adoption. The terminology in older glossaries covers canvas, WebGL, and user-agent — surfaces that are now table stakes. The new signals are where profiles actually get caught.

Which emerging signal causes the most bans in 2026?

Based on conversations with operators, ClientRects and WebGPU mismatches are the silent killers. Canvas and WebGL spoofing is mature — most antidetect browsers handle it. But ClientRects? Most tools don't touch it. And WebGPU exposes GPU identity through a completely different API path than WebGL. A profile claiming Intel UHD through WebGL but leaking RTX 3070 through WebGPU has impossible hardware. Platforms catch that contradiction trivially.

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

Both. FingerprintJS Pro, PerimeterX (now HUMAN), and DataDome have all added ClientRects and WebGPU to their fingerprint stacks since late 2025. Platform-side, Amazon and Meta run proprietary detection that queries these surfaces — operators have confirmed bans that correlate with ClientRects inconsistencies when other signals were clean. The academic-to-production pipeline for fingerprinting techniques is now under 18 months.

How do I test whether my antidetect browser covers these signals?

Run the JavaScript snippets in each section of this glossary against your profile. Check whether ClientRects returns consistent values across restarts, whether WebGPU adapter info matches your WebGL renderer, whether Network Info reports plausible values for your spoofed connection type. BrowserScan and CreepJS have added some of these checks, but not all. Manual verification against the API queries in this glossary is still the gold standard.

Try JustBrowser

Native Chromium antidetect browser — not extension-based. Real C++ engine patches at the canvas / WebGL / audio / font / screen layer, so 40+ identity parameters are genuine, not faked. REST API 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