A modern detector doesn't look at any single signal. It samples thirty or forty browser-level values, hashes them into a composite, and compares the composite against recent visits. If it has seen the same composite before — especially against a different account — the visit is suspicious by definition. This piece walks through the categories of signals a 2026-era detector cares about, what each one leaks, and what a serious anti-detect engine has to do about each.
Visual stack
Canvas
Ask the browser to render a string with mixed Unicode characters and a couple of fill colours, then read the pixel buffer back. The result is a 30 KB blob whose hash depends on the GPU driver, font rasteriser, OS-level subpixel rendering, and the system's installed font files. In practice the canvas hash narrows the visitor down to a few thousand machines at most. Per-profile spoofing means injecting deterministic noise into the read-back path so two profiles on the same machine produce two distinct, stable hashes.
WebGL
The browser exposes the GPU vendor and renderer strings (“Apple M1”, “NVIDIA GeForce RTX 4090”) and lets a script render a complex scene to a framebuffer and read it back. The render output, like the canvas, is GPU-driver-specific down to the bit. A serious spoofer needs to handle both sides — the metadata strings and the actual render output — because cheap spoofers often only do the first.
Audio stack
AudioContext.getChannelData and AnalyserNode.getFloatFrequencyData expose the floating- point output of the system's audio pipeline. Different OS audio stacks emit subtly different rounding artefacts. The fix is to wrap the buffer return with deterministic per-profile noise small enough that it doesn't affect actual audio playback.
Network stack
WebRTC
WebRTC's ICE candidate gathering reveals every IP address attached to the host machine, including local subnet addresses and any VPN tunnel endpoints. A correctly configured anti-detect browser blocks ICE candidate generation entirely, or returns only the proxy-routed public IP. Sites that legitimately need WebRTC (video calling) need an opt-out per profile.
TLS fingerprint (JA3 / JA4)
This one happens at the OS / library level before any browser JavaScript runs. The TLS handshake ordering of cipher suites and extension blocks is consistent for a given Chromium build. If you spoof the User-Agent to claim Firefox but ship a Chromium TLS handshake, every detector sees through the lie. The only fix is to either run a real Chromium fork (and accept the JA3 of that fork as ground truth) or use a TLS library that mimics other browsers' handshakes — and for browser-based ops the former is the only honest path.
Hardware and locale
- Screen. width, height, colorDepth, devicePixelRatio. Spoofing these is straightforward and any honest engine handles it.
- Time zone & language. Intl.DateTimeFormat and navigator.languages. Detectors compare these against the IP's GeoIP location — a profile claiming to be in Tokyo from a German residential proxy is a red flag.
- Hardware concurrency. navigator.hardwareConcurrency. Stable per machine; spoof per profile to a plausible value.
- Battery. The Battery API has been deprecated in most browsers but still exists in others. Per-profile spoofing avoids leaking actual battery state.
- Sensors. Accelerometer / gyroscope on mobile profiles need spoofed, plausible noise — flat-zero values are a tell.
- Permissions API. The browser's Permissions API can be queried to learn which capabilities (notifications, geolocation, midi) the user has granted. Stable per-profile rather than per-site.
Fonts
Detectors enumerate installed fonts by trying to render text in each font and measuring the resulting bounding box. A machine's font set is highly identifying. Spoofing means restricting profile-visible fonts to a per-profile subset that's consistent with the rest of the profile's claimed OS / locale.
Behavioural
Beyond the static fingerprint, modern detectors collect mouse-movement traces, typing cadence, scroll velocity, and request-timing patterns. There's no way to spoof behaviour without actually behaving differently — this is where multi-window sync helps (a master browser's mouse and keyboard input is replayed across slave profiles, so each profile's behavioural signature is different from the others even though the human is the same).
The composite problem
Each spoofer above defends one signal. The composite-fingerprint problem is harder: even if every individual signal is consistent in isolation, the combination needs to be plausible. A profile claiming to be a Mac (from the WebGL renderer string) but reporting Windows fonts and a Linux time-zone string is obviously fake. A serious anti-detect engine ships its profile presets as coherent device profiles — every signal sourced from the same real-world fingerprint snapshot — rather than spoofing each signal independently.
The detection benchmark question
The only way to know how well an engine actually performs against the live detector landscape is to run all of the major detectors against it on a schedule and publish the results. CreepJS, FingerprintJS, BotD, BrowserLeaks, IPHey, Pixelscan — these are the standard third-party benchmarks. Ours is published daily. Ask any anti-detect vendor for theirs; the absence of a public benchmark is itself a strong signal.