Browser Fingerprint Test: Check Canvas, WebGL, Audio & Device Uniqueness

Changing only your User-Agent header not only fails to disguise your browser, but also creates glaring "cross-layer contradictions" that trigger advanced fraud detection: First, application layer vs. transport stack mismatch: if you set a Windows browser UA to iPhone Safari, your HTTP header claims Apple mobile, but your TCP SYN packet presents a Windows kernel signature (no TS option and option order MSS, NOP, WS, NOP, NOP, SACK_PERM), directly contradicting Apple's 8-option sequence. Second, HTTP/3 and HTTP/2 protocol invariants: Chromium, WebKit, and Gecko engines differ in unforgeable ways, such as HTTP/3 unidirectional stream type mappings (Chromium: 2:control,10:encoder vs. WebKit: 2:control,6:encoder) and HTTP/2 pseudo-header ordering (Chromium: m,a,s,p vs. non-Chromium: m,s,a,p). Changing a UA string modifies only a superficial header while leaving the lower transport layers in direct conflict.

💡 Learn more about transport-level signatures in our Proxy Anonymity Analysis.

Anti-detect browsers typically patch Chromium or inject JavaScript hooks to override navigator properties, inject noise into Canvas/WebGL outputs, and simulate screen or audio contexts. However, advanced detection systems easily spot telltale artifacts: First, prototype and native function tampering: JS proxying and API monkey-patching often alter Function.prototype.toString, Object.getOwnPropertyDescriptor, and prototype inheritance chains. Second, GPU and shader invariants: while injected noise alters the rendered image hash, physical GPU floating-point precision and shader rasterization patterns remain fixed; artificial noise often forms an easily identifiable signature itself. Third, untouched underlying network stacks: most anti-detect browsers operate only at the JavaScript level and do not simulate the host operating system's TCP/TLS handshake characteristics.

No. Incognito mode is designed exclusively to prevent "local browsing traces on your own device," not to prevent "remote identification by websites." When an incognito window closes, local cookies, localStorage, and history are discarded. However, browser fingerprinting works by measuring physical hardware and software attributes via JavaScript (including GPU graphics rendering, WebGL shader precision, installed fonts, audio oscillator response, CPU concurrency, and color depth). Because your physical hardware, graphics drivers, and browser rendering engine are identical in incognito mode, the resulting fingerprint hash generated by remote servers is unchanged.

This is not a false positive—it reflects the fundamental architecture of iOS: First, Apple App Store Guidelines mandate that all web browsers on iOS/iPadOS (including Chrome, Edge, Firefox, and Opera) must use Apple's WKWebView / WebKit rendering engine and are prohibited from running Chromium Blink or Gecko engines. Second, protocol verification: on iOS, Chrome (CriOS) exhibits WebKit-exclusive HTTP/3 stream mapping (2:control,6:encoder), completely distinct from Chromium on desktop or Android (2:control,10:encoder). Chrome on iOS is effectively a WebKit browser with a Google user interface, and identifying it as WebKit is technically accurate.

Yes, but under strict conditions and clear limits, and this is entirely different from user authentication. Identity recovery on this site uses a four-layer weighting model: 1) Hardware Anchor Layer (GPU model string, audio base latency, media device counts); 2) System High-Entropy Layer (installed fonts list, speech synthesis voices); 3) Browser Mutable Layer (Canvas rendering hash, AudioContext computation hash); 4) Display Environment Layer (screen resolution, timezone). After aggregating all four layers, both of the following conditions must be met simultaneously to claim an existing identity: the total score must cross the threshold, and at least one high-entropy core feature must match (fonts list, voice synthesis list, Canvas, or Audio). This second condition is deliberate: public low-entropy attributes like GPU model, timezone, and screen resolution repeat widely across identical hardware batches, and no combination of them is permitted to establish identity on its own; earlier versions without this gate could mistakenly match two distinct strangers. Furthermore, the hardware anchor layer enforces a strict veto: if CPU logical cores differ, memory differs by more than 4GB, audio base latency differs by more than 0.005 seconds, or max touch points differ, the candidate is immediately classified as a different machine and excluded prior to scoring.

⚠ The goal of this mechanism is to consistently align repeated observations from the same device, not to prove who you are—it does not constitute identity authentication and must never be used as such.

Both are "system high-entropy features" that require no permissions and run completely silently without visible page artifacts. AudioContext Fingerprinting: Renders an audio buffer offline in an OfflineAudioContext by piping an Oscillator through a DynamicsCompressor, reading back floating-point sample values and hashing them. The same audio processing graph yields tiny least-significant-bit discrepancies across different browser implementations, math libraries, and floating-point backends, all without playing any audible sound. Adjacent to it but strictly independent is AudioContext.baseLatency: this value reflects the audio card output buffer size governed by audio drivers and hardware; our system treats it as a hardware anchor (a difference exceeding 0.005 seconds immediately disqualifies a match) rather than an identity hash—they have different origins and should not be conflated. Font Enumeration Fingerprinting: Measures the bounding box of a test string rendered with each font from a candidate list against default fallback fonts; discrepancies indicate the font is installed. Installed fonts reflect the software installed on your machine (suites like Office, Adobe, dev tools, and IME packs bring distinct fonts), making the font list typically the single highest-discriminating metric in the entire feature set.

💡 The stability difference stems from what triggers changes: Canvas and Audio hashes drift whenever the browser version updates (due to rendering engine and math library changes), whereas the font list only changes when you install or remove software—which is why it carries the highest weight.

MSS (Maximum Segment Size) is the maximum payload per TCP segment announced during the TCP handshake. Our server reads it directly from your SYN packet without requiring any client software or configuration. Adding back the IP and TCP header overhead reconstructs the MTU of the link: add 40 bytes for IPv4, add 60 bytes for IPv6. Common values carry distinct technical meanings: 1500 indicates standard Ethernet or bare-metal cloud links; 1492 indicates PPPoE broadband (DSL / FTTH residential connections), where the 8-byte PPPoE header reduces payload; less than or equal to 1420 indicates an additional encapsulation layer, typically from VPN tunnels like WireGuard / Tailscale or CDN origin proxies.

⚠ The key point is: MSS describes the network link, not your device. It can only indicate that "encapsulation exists along this path," and on its own does not prove proxy usage—residential PPPoE is also not 1500. What provides genuine diagnostic value is contradiction: when the location claimed by the application layer persistently conflicts with transport link attributes (such as claiming a local direct connection while MSS consistently falls in a tunnel range), that constitutes a meaningful signal. See Proxy Anonymity Analysis for details.

This is the error type we treat with the highest severity (false positive merge), and we guard against it with three sequential lines of defense—if any defense triggers, recovery is rejected. First, Hard Bucket Isolation: Candidate identities are partitioned strictly by OS platform and browser engine core, with zero cross-bucket comparisons—meaning two different browser engines on the same physical machine, even with identical hardware parameters, will never be merged into one identity. Second, Hardware Anchor Veto: CPU logical core counts, RAM capacity (4GB tolerance), audio base latency (0.005 seconds tolerance), and max touch points: if both sides report values that conflict beyond tolerance, the candidate is discarded before scoring. Third, Core Feature Admission Gate: Even with a high composite score, if the candidate matches zero high-entropy core features (fonts, voices, Canvas, Audio), claim is denied—this gate specifically prevents a cluster of public low-entropy attributes from accumulating an unearned high score.

⚠ Honest disclosure: We currently have no measured false-merge rate from organic production traffic to publish. This metric requires long-term longitudinal live traffic to quantify accurately; stating any percentage before reaching adequate sample size would be dishonest.