Antidetect browsers spoof a clean fingerprint on purpose. How they work, why some uses are legitimate, and how consistency checks catch them anyway.
What is an antidetect browser?
An antidetect browser is a commercial tool built to run many separate, disguised browser identities from one machine. Each profile gets its own randomized fingerprint: user agent, screen size, timezone, fonts, canvas and WebGL output. To a site, it looks like a different person on every session. Multilogin, GoLogin, Kameleo, and the open-source BotBrowser are the best-known names in the category.
This is a different trick than a stealth plugin patching one browser at runtime. A tool like puppeteer-extra-stealth overwrites a handful of automation tells after the page loads: navigator.webdriver, a missing plugins array. An antidetect browser goes further. It randomizes or actively falsifies the fingerprinting surface itself: canvas rendering, WebGL renderer strings, installed fonts, audio processing output, even which media devices the browser reports. Every profile is built to look like a distinct, real device, not a patched one.
Most of that spoofing supports something ordinary. Some of it doesn't.
Why antidetect browsers matter now
Ad agencies managing dozens of client accounts use antidetect browsers every day. One profile per client keeps campaigns from tripping each other's ad-platform limits. Researchers running geo-targeted market checks use them the same way. Neither use case is the problem.
The problem is the same tool applied to one operator hiding behind many identities. Credential-stuffing traffic runs faster and lasts longer when each login attempt carries its own clean fingerprint instead of reusing one flagged device. A promo or referral program built on "one account, one signup bonus" breaks down when a bot farm runs the sign-up flow behind a fresh fingerprint every time, the same pattern this site's promo abuse and multi-accounting use case already describes, just with the specific tool named. Affiliate programs and subscription services see the same shape: one paying customer's credentials or referral link, run through a hundred "different" browsers.
None of this requires a botnet or unusual infrastructure. It requires one operator, one antidetect browser license, and a target with a form worth automating. That's the part a fingerprint check alone can't see: a hundred different-looking sessions can still be one operator.
How an antidetect browser spoofs a fingerprint
Canvas fingerprinting is the layer antidetect browsers work hardest to fake, because it isn't self-reported the way a user agent string is. When a page draws to an HTML5 canvas element and reads the pixels back, the exact output depends on the real graphics driver and hardware doing the rendering. Two different GPUs render the same drawing instructions into slightly different pixels. That's a signal JavaScript can't just declare a different value for. It has to be faked at the rendering layer itself.
So antidetect tools intercept the canvas and WebGL APIs and inject noise before the page ever reads the result: a randomized pixel here, a different WebGL renderer string there. The same trick extends to installed fonts, audio processing output (an AudioContext fingerprint depends on real audio hardware the same way canvas depends on a real GPU), and the exact set of media devices the browser reports.
Randomizing one attribute is easy. Keeping every attribute consistent with all the others, so they still describe one coherent, plausible device, is not.
Two ways antidetect browsers are built
Two different engineering approaches show up across the antidetect market, and they trade off differently.
The first patches a real, stock browser's fingerprint-emitting APIs at runtime or install time. Kameleo modifies Chromium, Firefox, and WebKit this way. GoLogin and similar cloud-based tools work the same way, aimed at freelancers and small teams running a handful of accounts. This is fast to build and cheap to run. But the patch itself is a trace: overriding navigator.platform or a canvas API leaves the property redefined in a way a real browser's own implementation never would be.
The second approach builds fingerprint spoofing into the engine itself, at the C++ level, before compilation. It's the same strategy patched Chromium builds use to hide automation tells. BotBrowser and Camoufox work this way, and it buys something specific: the same fingerprint configuration can reproduce identically across Windows, macOS, Linux, and Android. That consistency sounds like an advantage. It's also backwards. A real device's fingerprint is supposed to vary with its actual hardware and OS. A fingerprint that stays identical across four different platforms was never attached to a real device in the first place.
How to catch an antidetect browser despite a clean fingerprint
None of this holds up to a consistency check, because spoofing a fingerprint attribute and keeping it consistent with everything else the browser reports are two different problems.
Canvas spoofing is one example. You can compare how a page renders canvas output on the main thread against how it renders inside a Web Worker. A real browser produces identical results in both contexts. A canvas patch applied at one layer often doesn't propagate identically to the other, so the two renders come back with a different hash. That mismatch alone is the tell.
The same logic applies to JavaScript's own object model. A real browser inherits properties like navigator.platform from its prototype chain. A patched one frequently redefines the property directly on the object instead. Walking the prototype chain and checking whether a property is genuinely inherited or freshly overwritten catches that. Calling .toString() on a patched function is another version of the same trick: a browser's real built-in functions return [native code], while a JavaScript override reveals the actual function body instead.
Some signals sit entirely outside what an antidetect browser can touch. The TLS handshake and the HTTP/2 SETTINGS frame both arrive before a single line of page JavaScript runs. A tool that spoofs the fingerprint at the JS layer has no way to reach either one, so a session claiming to be Safari while carrying Chrome's TLS fingerprint gives itself away before the page finishes loading, the same JA4 mismatch problem already documented for scraper detection generally.
Academic researchers at UC Davis put a number on the broader pattern. They ran a honeypot site behind two bot-detection services and pulled in traffic from 20 different bot services across roughly 500,000 requests. The bots evaded detection 52.93% of the time against one service and 44.56% against the other (UC Davis, 2024), and they did it by spoofing individual attributes, not by keeping the whole fingerprint internally consistent. Detection rules built around that inconsistency cut the evasion rate by roughly half.
No single attribute proves a fingerprint is fake. Whether it holds together does.
Key takeaways
- An antidetect browser isn't a stealth plugin patching a few automation flags after page load. It randomizes or actively falsifies the fingerprinting surface itself, so each profile looks like a distinct, real device.
- Legitimate use is real: ad agencies running multiple client accounts, researchers doing geo-targeted checks. So is the abuse: credential stuffing with a clean fingerprint per attempt, and referral or affiliate fraud run through a hundred "different" browsers.
- Two build approaches exist, and both leave a trace. Runtime patches on a real browser (Kameleo, GoLogin) leave the patch itself as a signal. Engine-level spoofing (BotBrowser, Camoufox) buys a fingerprint that reproduces identically across platforms, which is itself unnatural, since a real device's fingerprint should vary with its real hardware and OS.
- No single fingerprint attribute proves a session is fake. What UC Davis's research found, and what Centinel checks for at the edge, is whether everything a session reports holds together: canvas across contexts, prototype chains, TLS against the claimed browser, behavior across a session. A profile can look clean on any one signal and still fail the consistency check.