Anti-detect browsers are the high-end automation stack. They are real Chromium and Firefox builds modified to expose a configurable, internally-consistent fingerprint per profile, so an operator can run dozens or hundreds of accounts in parallel and have each one look like a different real device. They are sold openly, used legitimately for some workflows and abusively for many others, and they are the hardest commercial automation product to detect today. This article covers what they actually do under the hood and the cross-layer signals that still catch them.

If you have read browser fingerprinting techniques and bot detection, this is the next step. Anti-detect browsers are interesting precisely because they invest in beating the per-signal checks. The defense has to invest in the joint distribution instead.

What an anti-detect browser is

An anti-detect browser is a customized browser distribution whose purpose is to make a single physical device present itself as many distinct browsers to device fingerprinting checks. The operator creates a “profile” per identity, each with a unique configured fingerprint (OS, screen size, GPU, fonts, time zone, language, canvas behavior, etc.), and runs each profile in a separate isolated environment. The same machine can run hundreds of profiles, each looking like a different consumer device.

The major commercial products as of 2026:

  • Multilogin. Pioneered the category. Maintains its own Chromium and Firefox branches. Enterprise pricing. Heaviest investment in spoofing every fingerprintable surface rather than disabling them.
  • Octo Browser. Originally based on Multilogin’s playbook, now its own engineering. Strong on canvas and WebGL spoofing.
  • Dolphin Anty. Popular in the affiliate marketing world. Tends toward affordability and volume rather than perfect stealth; users report fingerprint leaks above a few hundred profiles per machine.
  • GoLogin. Built on Orbita, a custom anonymous-mode browser. Strong mobile profile support.
  • AdsPower. Popular in advertising operations. Per-profile automation tools.
  • Kameleo. Strong on mobile browser emulation.
  • Indigo Browser, Incogniton, DICloak, BitBrowser, undetectable.io, Nstbrowser. A long tail of alternatives.

These are not bot frameworks in the Selenium or Puppeteer sense but browsers that human operators (and increasingly, scripts on top of them) drive. The threat model they address is “this site is fingerprinting me and I want each of my accounts to look like a different person.”

Why they are hard to detect at the per-signal layer

The whole point of an anti-detect browser is to defeat individual fingerprinting probes. They invest engineering effort in:

Canvas spoofing. Rather than blocking the canvas API (which would itself be a tell), high-end anti-detect browsers procedurally generate canvas output that varies per profile and is internally consistent with a plausible GPU. Multilogin in particular has built its product positioning around full canvas spoofing rather than canvas blocking.

WebGL spoofing. The UNMASKED_RENDERER_WEBGL string and the WebGL parameters are set to match the claimed GPU. The actual 3D rendering output is also adjusted to look like that GPU. This is harder than canvas spoofing because the output has to be physically plausible.

AudioContext spoofing. Procedurally generated audio fingerprint variants per profile.

Font fingerprint spoofing. The font list is set per profile to match a plausible OS installation. The candidate fonts are actually rendered using the claimed metrics.

TLS fingerprint spoofing. This is the genuinely hard one. Multilogin and a few others maintain custom Chromium builds with TLS stack modifications so that the JA3/JA4 fingerprint matches the claimed Chrome version on the claimed OS, even when the underlying machine is a Linux server.

Client Hints and User-Agent consistency. The User-Agent, Sec-CH-UA, Sec-CH-UA-Platform, Sec-CH-UA-Platform-Version and high-entropy hints are all set together so they describe a single coherent environment.

Time zone, locale and language consistency. Profile configuration sets all three to match a plausible geography that matches the proxy the operator pairs with the profile.

A well-configured anti-detect browser profile passes every single-signal fingerprinting check at the JS environment layer, because that is precisely what the product is built and sold to do.

Where they still leak

The leaks are at the layers anti-detect browsers cannot fully control without becoming a fundamentally different product.

1. Cross-profile cluster signals

A single anti-detect browser instance runs many profiles on one physical device. Each profile is engineered to look unique, but the operator’s operational patterns are not.

  • All the profiles tend to use the same proxy provider, even if they rotate through different residential exits.
  • All the profiles run at the same hours of the day.
  • All the profiles exhibit similar navigation patterns: same site, same flow, same dwell times.
  • All the profiles arrive at the target service through the same referrer pattern.

A detector that bucket-sorts sessions by a cluster signature (proxy provider + ASN + behavioral-pattern hash + hour-of-day) will see the operator’s whole farm cluster together, even when each individual session looks unique.

Dolphin Anty’s own documentation acknowledges this: platforms catch multi-accounting by detecting overlaps between profiles rather than by recognizing individual profiles (Dolphin Anty: Multi-Accounting Errors).

2. Behavioral-pattern consistency

A human operator running 50 profiles produces 50 sessions with similar behavioral patterns. The same operator clicks in the same places, scrolls at the same speed, types at the same tempo, takes the same pauses. Behavioral analytics that fingerprints not just “is this a human” but “is this the same human” can cluster sessions on this signature.

The defense the operator has is to script the work, which introduces the standard automation tells (uniform inter-action timings, lack of micro-noise in mouse trajectories) that bot detection already catches.

3. Hardware ground truth

Some signals are observable from inside the browser but are determined by the underlying hardware. Performance timings, microbenchmarks, the precision of performance.now() clamped by the browser version, the actual latency profile of requestAnimationFrame. These describe the host machine, not the claimed device.

A profile claiming to be a fresh MacBook Air running on a Hetzner Linux server will show benchmark timings consistent with the server’s hardware, not the MacBook. Detectors that include short, cheap timing probes (a 50-ms compute task, an animation-frame stability check) can catch this without expensive analysis.

4. TLS extension fingerprints under the new JA4 family

JA3 was sortable, and Chrome 110+ began randomising the TLS extension order specifically to defeat JA3. Anti-detect browsers that targeted JA3 spoofing got real-Chrome-like JA3 hashes. The newer JA4 family sorts the extensions before hashing and adds more granular sub-fingerprints (JA4S for the server response, JA4H for HTTP headers). Spoofing the full JA4+ surface is harder than spoofing JA3.

5. Web Bot Auth’s negative signal

If a site allows verified AI agents through Web Bot Auth and treats anonymous browser sessions with extra scrutiny, anti-detect browsers fall into the scrutinised category by definition. The presence or absence of a valid signature becomes its own classification axis.

6. Device-level cross-checks on mobile

Profiles claiming to be specific mobile devices have to satisfy mobile-specific cross-checks: User-Agent vs hardware sensors, touch point capabilities vs claimed screen size, mobile-specific viewport quirks. Mobile-emulating anti-detect browser profiles often fail these because the actual touch input does not exist.

Detection strategy

Catching anti-detect browsers reliably requires a different posture from catching Puppeteer. The signals that catch Puppeteer (named globals, CDP attachment, named tells) are exactly what anti-detect browsers exist to suppress. The signals that catch anti-detect browsers are at higher levels of abstraction.

Strategy 1: Joint-distribution checks

For every session, compute a joint signature across signals that are usually independent:

  • Canvas hash + WebGL renderer + GPU benchmark timing + font set.
  • Time zone + locale + IP geolocation + clock skew.
  • TLS fingerprint + claimed UA + Client Hints + JA4H header fingerprint.

A real device produces a coherent joint distribution. A spoofed profile produces values that are individually plausible but jointly inconsistent.

Strategy 2: Cluster signatures

For every session, compute features that describe the operator rather than the profile:

  • Proxy provider (inferred from IP + ASN reputation database).
  • Hour-of-day pattern.
  • Behavioral cluster ID (derived from interaction features).
  • Referrer pattern.
  • Navigation flow shape.

Sessions from one anti-detect operator cluster together on these features.

Strategy 3: Cheap timing probes

Add small, cheap server-evaluated timing probes:

  • A short JavaScript benchmark whose runtime is bucketed.
  • An animation-frame stability check over a few hundred frames.
  • A network-timing measurement that compares perceived RTT to expected RTT for the claimed geography.

These catch the hardware ground-truth mismatch without expensive analysis.

Strategy 4: Mobile-specific cross-checks

If the profile claims a mobile device:

  • Verify touch capability is real, not just maxTouchPoints > 0.
  • Verify motion sensor data (where permitted) matches a device that is actually held.
  • Verify the viewport quirks that differ between iOS Safari and Android Chrome.

Strategy 5: Account graph signals

When you have account history:

  • Multiple accounts logging in from the same anti-detect-browser cluster signature.
  • Multiple accounts performing identical actions in identical sequences.
  • Multiple accounts created from device fingerprints that look unique individually but share infrastructure markers.

The account graph is the layer that catches the most sophisticated operations because no individual fingerprint can hide that the same operator created and runs the accounts.

The legitimate uses are real

Anti-detect browsers have legitimate use cases worth being honest about:

  • Affiliate marketing professionals managing multiple ad accounts across platforms that allow multi-accounting in some forms.
  • Web scraping for permitted use cases (research, journalism, accessibility crawlers) on sites that block IP-rotation but allow distinct user identities.
  • Social media management agencies operating on behalf of many clients.
  • Penetration testers and security researchers simulating populations of distinct users.

Treating “anti-detect browser detected” as automatic block-the-session would harm these uses. The mature policy is to flag anti-detect browser sessions, hold them to higher per-account verification standards (real KYC, real billing relationships, real behavioral plausibility), and apply hard blocks only when the flag is paired with other strong signals.

What the flag should trigger depends on the product. A marketplace or social platform can afford to let a flagged session proceed and watch what the account actually does (listing patterns, messaging behavior, payout requests) before acting. A fintech onboarding flow with regulatory exposure has much less room, and a hard gate at signup is defensible there. In both cases the reliable pattern is the same: pair the browser signal with account behavior before making an irreversible decision.

How Foil approaches it

When Foil identifies an anti-detect browser, the session carries an attribution label of kind evasion with the value anti-detect-browser and a confidence score; sessions built on the Camoufox engine surface with the value camoufox. The same sessions typically show elevated runtime_integrity.identity_spoofing and runtime_integrity.tampering. The products described above (Multilogin, Octo, Dolphin Anty, GoLogin, AdsPower, Kameleo and the long tail) are the population this classification detects; the API value is the general label rather than a per-vendor code. Classification combines:

  • Joint-distribution checks for known anti-detect browser product signatures.
  • Cluster signature computation across recent sessions.
  • Cheap timing and benchmark probes.
  • Behavioral pattern matching.
  • Account graph signals when account context is available.

The session explains which evidence fired through the attribution labels and the runtime-integrity flags. The application decides what to do with it, applying the kind of product-specific tolerance described above.

The full bot-detection picture is in bot detection, the policy layer is in bot management, and the application-layer mitigation patterns are in bot mitigation.

Further reading