Skip to content

Anti-detect browsers compared: Multilogin, GoLogin, Dolphin, and Incogniton internals

· 26 min read
Copyright: MIT
anti-detect-browser browser-automation fingerprinting
Wordmark reading anti-detect browsers with an orange underline and a list of the four products compared

Four products dominate the conversation when someone says “anti-detect browser”: Multilogin, GoLogin, Dolphin Anty, and Incogniton. They sell the same promise. Run fifty Instagram accounts, or three hundred ad accounts, or a fleet of marketplace seller profiles from one machine, and have each one look to the server like a separate person on a separate device. The marketing copy is interchangeable. The internals are not. One of these ships a Firefox fork alongside its Chromium one. One spent years as essentially a patched Chromium with a profile manager bolted on top. One was built by a traffic-arbitrage operator and reads like it. And the gap between “changes the value JavaScript reads” and “changes the value the C++ produces before JavaScript ever sees it” is the whole technical story.

This post is a reference for that story. It does not rank the products and it does not tell you how to defeat any specific detector. It walks what each browser is actually built on, how a profile stores and replays a fingerprint, where the spoofing happens in the rendering stack, and the recurring way these tools get caught: not by any single wrong value, but by combinations that no real device would ever produce together.

The sections below go from the foundation up. First the fork question, because Chromium-versus-Firefox decides what is even possible. Then the profile model that every one of these shares. Then the hard part, canvas and WebGL and audio, where naive randomization gets you flagged faster than no spoofing at all. Then a per-product pass on Multilogin, GoLogin, Dolphin, and Incogniton. Then the detection seams, and a closing note on why the consistency problem is the one that actually matters.

What each one forks

Every product in this comparison is a fork of an existing browser, not a browser written from scratch. That sounds obvious but it is the single most important fact about how they work, because the fork decides which surfaces the vendor can reach into and which ones they are stuck spoofing from the outside.

Three of the four are pure Chromium. GoLogin ships a Chromium fork it calls Orbita, which it has built and maintained since the company started up around 2019. Dolphin Anty, created in 2021, describes itself as Chromium “with its own kernel modifications.” Incogniton is Chromium-based and leans on profile isolation plus fingerprint randomization rather than any deep engine rewrite. Multilogin is the outlier. It runs two engines: Mimic, a Chromium fork, and Stealthfox, a Firefox fork. For a long time Stealthfox was the original Multilogin engine, and Mimic came later as the Chromium answer. Multilogin’s own current positioning treats Mimic as the modern default and frames Stealthfox as the Firefox option you reach for when a target platform expects Firefox traffic and Chromium-shaped traffic would itself look odd.

base engine product fork Chromium Firefox Mimic (Multilogin) Orbita (GoLogin) Dolphin Anty Incogniton Stealthfox (Multilogin) *Three of the four are Chromium-only. Multilogin is the lone vendor shipping a Firefox engine alongside its Chromium one, which lets it present Firefox-specific fingerprint surfaces that a Chromium fork cannot fake.*

The Firefox option matters more than it looks. A Chromium fork can spoof its user agent to claim it is Firefox, but the moment a page touches a Gecko-specific surface, the lie shows. Firefox and Chromium differ in their JavaScript engine quirks, their CSS property support, the exact shape of their navigator object, the way they expose media codecs, and dozens of smaller behaviors that fingerprinting scripts probe precisely because they are hard to fake. A real Firefox fork answers those probes the way real Firefox does, because it is real Firefox underneath. That is the entire argument for Stealthfox existing, and it is why “just spoof the UA string” was never enough to impersonate a different engine.

The flip side is cost. Chromium has the dominant market share, so a Chromium fork blends into the largest crowd by default, and most automation tooling, from Puppeteer to Playwright to Selenium, speaks Chromium’s debugging protocol natively. Maintaining a Firefox fork in parallel is real engineering overhead for a smaller slice of traffic. That tradeoff explains why three of these four vendors never bothered, and why Multilogin’s own messaging now nudges users toward the Chromium engine as the default while keeping the Firefox one available for the cases where it genuinely helps.

The profile model everyone shares

Under the fork differences, all four products implement the same core abstraction: the profile. A profile is a saved bundle of two things. First, a fingerprint configuration, which is the set of values the browser will report for this identity. Second, an isolated storage container holding that identity’s cookies, localStorage, IndexedDB, cache, and session state. Launch a profile and you get a browser window that reports the saved fingerprint and reads and writes only that profile’s storage. Launch a second profile beside it and the two share nothing. No cookie leaks across, no localStorage key is visible to the other, and to each website the two windows look like two unrelated devices.

This isolation is the actual product. The fingerprint spoofing gets the marketing, but the reason someone pays for one of these instead of running incognito windows is that a profile is a durable, separable identity you can store, clone, hand to a teammate, and run a thousand of without them contaminating each other. GoLogin describes each profile as a self-contained environment with its own cookie jar, localStorage, and cache, and pitches it as the effect of a virtual machine at a fraction of the cost and weight. Dolphin frames each profile as an isolated container, fully separated from the others. The language is near-identical across the four because the model is.

The fingerprint half of the profile is a configuration object, typically a JSON-shaped record, listing the values to report: operating system, user-agent string, screen resolution and color depth, hardware concurrency (CPU core count), device memory, timezone, language list, WebGL vendor and renderer strings, a canvas spoofing mode, an audio spoofing mode, a font list, WebRTC handling, and a few dozen more. GoLogin says it exposes roughly 50 to 53 of these parameters for tuning. Dolphin’s list runs through WebRTC, Canvas, WebGL, ClientRects, audio, timezone, language, geolocation, CPU, memory, screen, media devices, and ports. The exact field names inside each vendor’s profile format are not publicly documented, and you should treat any specific field-name claim about a closed-source profile schema with suspicion, but the categories are well established and consistent across the products.

one profile = config + isolated storage fingerprint config os, userAgent screen, colorDepth hardwareConcurrency deviceMemory timezone, languages webgl vendor/renderer canvas mode, audio mode fonts[], webrtc mode ... ~50 fields total isolated storage cookies localStorage IndexedDB cache session state nothing here is visible to any other profile *Every product implements the same two-part profile: a fingerprint configuration that decides what gets reported, and a storage container that no other profile can read. The isolation, not the spoofing, is what people pay for.*

Where the products diverge is storage location. Incogniton stores profile data locally by default, so the fingerprint configs, cookies, and session data stay on your machine and never leave it, with the cost that you cannot reach a profile from another computer without copying the data across yourself. Dolphin runs as local software too. GoLogin offers both: a local desktop app, and a cloud sync that encrypts profile data with AES-256 and stores it on cloud infrastructure so a team can share profiles, plus a fully remote “Cloud Browser” that runs the Orbita instance on GoLogin’s own servers and hands you a WebSocket endpoint to drive it. That cloud-versus-local split is a meaningful operational difference, and it is also a security one, because a synced profile is a fingerprint and a full cookie jar sitting on someone else’s server.

All four expose the same automation hook: connect Selenium, Puppeteer, or Playwright to a launched profile and drive it programmatically. Mechanically this works the way remote browser automation always works, by attaching over the browser’s debugging protocol, which for the Chromium-based engines is the Chrome DevTools Protocol. That attachment is itself a detection surface, and a notable one, which is why the way a driver connects matters as much as the fingerprint it presents. The CDP detection vector and the Runtime.enable leak are the relevant background there: an anti-detect browser can present a flawless fingerprint and still give itself away through how it is being driven.

Where the spoofing actually happens

Here is the line that separates a real anti-detect browser from a browser extension that claims to do the same thing. An extension runs in JavaScript, after the page’s JavaScript, and the best it can do is override a property or wrap a function on the page’s window. A forked browser changes the value down in the C++ before any JavaScript runs at all. The difference is not cosmetic. It decides whether the spoof is detectable by the page that is trying to detect it.

Take navigator.hardwareConcurrency, the CPU core count. An extension overrides the getter so reading the property returns, say, 8. But the override is itself a JavaScript object sitting on the prototype chain, and a detection script can inspect it. It can check whether the property’s getter is a native function or a replacement, read the function’s toString to see if it returns the native-code marker or some injected body, and walk the prototype to spot the wrapper. A browser fork sets the core count in the C++ that backs the Navigator interface, so the getter is the genuine native getter and it simply returns a different number. There is no wrapper to find. GoLogin describes its approach as an invisible layer between the site and your real environment that substitutes profile characteristics on the fly at the engine level, and contrasts it explicitly with plugin-based approaches. That contrast is the whole reason these are separate browsers and not extensions.

Canvas is where this gets genuinely hard, and where most of the engineering effort lives. Canvas fingerprinting works by asking the browser to draw text and shapes to an off-screen canvas and then read the pixels back, because the exact bytes that come out depend on the operating system, the GPU, the graphics driver, the font rasterizer, and the browser’s rendering settings, all in combination. Two machines with the same configuration produce the same pixels; a different configuration produces different pixels. The hash of those pixels is a stable, high-entropy identifier.

The naive way to spoof it is to add noise. Intercept the pixel readback, perturb each channel by a small random amount, and the hash changes. This is exactly what many browser extensions do and it is exactly the wrong approach, for a reason that took the industry a few years to fully absorb. Real browsers do not produce random canvas output. A given device renders a given canvas the same way every time. So when a detector sees canvas output that does not match any known real-device configuration and is unique on every read, it has not failed to identify you. It has positively identified you as something running canvas noise. Kameleo, a competitor in this space, published its own research making the point bluntly: once you apply random noise the hash will not match any valid configuration, it will be 100 percent unique, and it will be obvious that noise spoofing is in play. Castle, on the detection side, documented the complementary attack. Fill a canvas with a known color like rgba(0, 127, 255, 1), read specific pixels back, and check whether the channels hold the exact expected values. A noise injector that perturbs every channel fails that check, because it cannot tell a fingerprinting draw from a controlled-color one, and the controlled color comes back wrong.

naive noise read pixels + random shift hash unique every time matches no real device -> flagged matched-device spoof emulate target GPU/OS render hash = a real config's hash detector's check fill rgba(0,127,255,1) read back known pixel noise: channels wrong matched: channels exact + check toDataURL is native, not a wrapper + stack-trace probe *Random noise is the easy implementation and the detectable one. The harder goal is to produce the canvas hash a specific real device would produce, which is why vendors collect real fingerprints to copy rather than inventing them.*

The better approach, and the one the serious vendors converged on, is to make the canvas output match a real device’s output rather than be unique. Kameleo’s stated goal is a modified canvas hash that is non-unique, aligning with the spoofed device profile rather than standing out. They note in passing that a Windows 10 machine with a given GPU produces the same canvas hash across any recent Chromium-based browser version, which is what makes the target reproducible: there is a finite set of real-device hashes to imitate. This is why every vendor of consequence talks about collecting real fingerprints. Dolphin says outright that it collects real user fingerprints and generates client configurations from them. GoLogin describes automating config generation from a large corpus of real-world fingerprints. The corpus is the point. You cannot invent a coherent fingerprint; you have to copy one that exists.

There is a second school of thought worth naming because it is the rigorous version of the noise approach, and it is not what the multi-accounting browsers do. Brave’s “farbling” adds tiny per-session, per-site pseudo-random noise to canvas, WebGL, and Web Audio output, but the noise is deterministically seeded from a per-session, per-eTLD+1 seed. A given site reading the canvas twice in one session gets the same farbled value both times; a different site gets a different value; a new session reseeds. Brave’s goal is the opposite of the anti-detect browsers’ goal. It wants every visit to look unique so that nothing can be linked across sites, where the anti-detect browser wants each profile to look like one consistent real device. Brave cited the academic lineage when it shipped this, naming PriVaricator (Nikiforakis and colleagues, WWW 2015) and FPRandom (Laperdrix and colleagues, ESSoS 2017) as the prior work. It is a cleaner design than blind noise, and it still got broken. A 2025 ACM Web Conference paper, “Breaking the Shield: Analyzing and Attacking Canvas Fingerprinting Defenses in the Wild,” showed that the pixel noise Brave’s farbling adds can be recovered through statistical analysis, and concluded that no fully deployable defense against canvas fingerprinting currently exists. That finding cuts both ways: it is bad news for privacy browsers and bad news for spoofers, because the same statistical machinery that recovers Brave’s noise can flag an anti-detect browser’s noise.

WebGL is the same problem one layer deeper, and it constrains canvas. WebGL hands a script the GPU vendor and renderer strings directly, through the WEBGL_debug_renderer_info extension, and it also produces its own rendered-image fingerprint. The constraint is consistency. If a profile’s canvas output looks like it came from an NVIDIA GPU but the WebGL renderer string says Intel integrated graphics, the two contradict each other and a detector that checks the pair catches the mismatch instantly. So the canvas spoof, the WebGL renderer string, and the WebGL image fingerprint all have to come from the same real device, together. Audio fingerprinting, which reads the output of the Web Audio API’s signal processing and varies by platform, adds a third surface that has to agree with the other two. The engineering challenge across all of this is not faking one value. It is faking a whole consistent device, every surface agreeing with every other surface, the way a real machine’s would.

Multilogin

Multilogin is the veteran, an Estonian company that predates most of the field, and its dual-engine design is the clearest expression of taking the fork question seriously. Mimic is the Chromium engine and the modern default. Stealthfox is the Firefox engine and the original. The reason to keep both is the one from the fork section: some target platforms expect Chromium traffic and some expect Firefox, and presenting genuinely the wrong engine to a Gecko-aware fingerprinting script is worse than presenting a real but minority engine. Multilogin’s own writeups describe Stealthfox as covering Firefox-specific fingerprint signals that a pure Chromium tool simply cannot reproduce, which is true at the engine level and not just marketing, because a Chromium fork cannot make the Gecko surfaces answer like Gecko.

Multilogin’s account of its own history is candid about the limits of the old approach. By its description, early Stealthfox randomized or altered surface values like user agents, canvas, WebGL, and fonts, and lacked control over deeper signals like TLS fingerprinting and behavioral analytics. That is an honest summary of where first-generation anti-detect browsers sat: they handled the JavaScript-readable surface and left the network and behavioral layers exposed. The move to Mimic was the move to a more current Chromium base with more current spoofing, on the theory that a recent Chromium fork blends into the largest crowd and keeps pace with detection changes more easily than an aging Firefox fork. At the network level, the strongest claim made for Mimic is that it is meant to be indistinguishable from a real Chrome install on the wire, which is the bar that matters once the JavaScript surface is handled, because TLS and HTTP/2 fingerprints are checked before a single line of page script runs. The background on why that layer is decisive is in TLS fingerprinting: from ClientHello bytes to JA4.

The detail that Multilogin gets right conceptually is that the engine and the fingerprint config are separate decisions. You pick Mimic or Stealthfox for the base reality, then layer a profile’s spoofed values on top. That two-layer model is the correct mental picture for all four products, but Multilogin is the only one where the bottom layer can actually be a different browser engine rather than always Chromium wearing different clothes.

GoLogin

GoLogin’s engine is Orbita, a Chromium fork the company has run since roughly 2019, built because, in its own telling, neither Tor nor Chrome nor Firefox fit the requirements for an anti-detect base. Orbita is meant to look and behave exactly like Chrome down to the UI, while doing the engine-level value substitution described earlier. GoLogin is the product that most explicitly frames its spoofing as an invisible layer sitting between the site and your real environment, swapping profile characteristics on the fly, and it is the product most explicit about the 50-to-53-parameter config surface.

GoLogin is also the clearest on the cloud-versus-local question, because it does both and a third thing besides. The desktop app runs Orbita locally for Selenium and Puppeteer automation. The sync option encrypts profiles with AES-256 and stores them remotely so a team can share. And the Cloud Browser runs Orbita on GoLogin’s servers, reached over a WebSocket endpoint, so the browser never touches your machine at all. Each of those is a different threat model. A local profile keeps your cookies on your disk. A synced profile puts a complete identity, fingerprint plus cookie jar, on someone else’s infrastructure. A cloud-run browser means the vendor’s IP and the vendor’s machine are part of your fingerprint whether you think about it or not, which interacts with residential proxy and ASN detection in ways worth thinking through before you route traffic that way.

On fingerprint generation, GoLogin leans on the corpus approach, automating config creation from real-world fingerprints rather than asking the user to assemble a coherent device by hand. That is the right instinct, for the consistency reasons above, and it is the same instinct Dolphin states more bluntly. The recurring caveat is the one no vendor advertises: the corpus has to stay current. Real Chrome ships a new version every few weeks, and a fingerprint corpus collected last year describes a population of browsers that is now slightly out of date, which on its own is a faint but real signal if a detector tracks version distributions over time.

Dolphin Anty

Dolphin Anty arrived in 2021, built by Denis Zhitnyakov out of the traffic-arbitrage world, and the product reflects its origin. It is Chromium with kernel modifications, in its own words, and its feature set is tuned for people running large numbers of accounts for paid traffic rather than for privacy-minded individuals. The fingerprint surface it controls is the standard wide list, running through WebRTC, canvas, WebGL, ClientRects, audio, timezone, language, geolocation, CPU and memory, screen, media devices, and ports. ClientRects deserves a mention because it is one of the less-discussed surfaces: the sub-pixel geometry returned by getClientRects on rendered elements varies by platform and rendering settings, so it is one more thing that has to agree with the canvas and WebGL story for a profile to hold together.

Dolphin’s stated method for staying coherent is the corpus approach again, and it states it without hedging: it collects real user fingerprints and generates client configurations from them. That is the same answer GoLogin gives, and it is the correct answer, because the alternative, letting users dial in arbitrary combinations, is how you end up with impossible devices that a consistency check flags on sight.

Where Dolphin’s arbitrage heritage shows most is the automation layer. Beyond the standard Selenium and Puppeteer and Playwright hooks, it ships a built-in scenario builder for non-programmers and tools aimed squarely at multi-account operations: a Cookie Robot that sends a profile to browse real sites and accumulate a plausible cookie history before the account is used in anger, and a synchronizer that mirrors actions from one master profile across many subsidiary profiles in real time. The Cookie Robot is the interesting one, because it is an admission about how detection actually works. A profile with a pristine, empty cookie jar and no browsing history is itself suspicious, since real people accumulate cruft. Warming a profile up before use is a behavioral countermeasure layered on top of the fingerprint one, and the existence of a dedicated tool for it tells you the vendor knows the fingerprint alone does not carry the disguise.

It is worth noting that Dolphin is well-known enough that detection vendors discuss it by name. DataDome, for instance, maintains public material on classifying and detecting Dolphin Anty specifically. When a detection company writes up your tool by name, the spoofing is no longer a secret edge; it is a known pattern that the other side is actively modeling. That is the permanent condition of this market, and no vendor in it is exempt.

Incogniton

Incogniton is the most conventional of the four. It is Chromium-based, it generates a realistic, coherent, persistent fingerprint per profile rather than blocking or randomizing blindly, and it isolates each profile’s storage the way the others do. Its stated emphasis is on coherence: modifying user agent, canvas and WebGL rendering, screen resolution, and timezone together in a way that looks natural, so each profile reads as a distinct real user on a distinct device. That is the right goal, stated plainly.

The honest knock on Incogniton, which even comparison writeups make, is that it leans on Chromium-based randomization without a proprietary engine doing deeper work, where the goal of matching real devices, rather than merely varying values, is the thing that separates current-generation spoofing from the previous one. Incogniton also stores profiles locally on Windows or macOS with no cloud browser option, which is a privacy positive (your data stays on your machine) and an operational limit (you cannot reach a profile from another device without copying it). For a single operator running a moderate number of profiles, local-only and coherent-by-default is a reasonable design. For someone trying to defeat a current commercial detector at scale, the absence of deeper engine work and a fresh real-device corpus is where the seams would show first.

Where the seams show

Step back from the products and the detection story collapses to one idea: nobody catches an anti-detect browser by finding a single wrong value, because the vendors fixed the single wrong values years ago. They catch it by finding combinations that no real device produces.

The canvas-versus-WebGL contradiction is the textbook case. Canvas output implying one GPU, WebGL renderer string naming another, and the pair is impossible on real hardware. Around that sit a dozen similar consistency checks. A user agent claiming a macOS build while the WebGL renderer names a GPU that ships in Windows laptops. A timezone that disagrees with the IP’s geolocation. A hardwareConcurrency of 4 paired with a deviceMemory of 64, a combination that real machines rarely present. A font list that includes fonts which never ship together on the claimed operating system. None of these is a wrong value on its own. Each is a wrong relationship between values, and relationships are exactly what an arbitrary user-configured profile gets wrong and what a corpus-derived one gets right. This is why every serious vendor talks about coherence and real fingerprints, and why the noisy, randomize-everything extensions get caught fastest.

each value passes alone userAgent = macOS webgl = Intel (Win laptop GPU) timezone = Europe/Kyiv ip geo = Brazil fonts = Win-only set the combination impossible no real device looks like all five at once *Detection by inconsistency is the durable attack. The vendors long ago stopped emitting individually-wrong values; what trips a profile is a relationship between values that no real machine would present together.*

The second class of seam is the driver, not the fingerprint. All four products let you attach Selenium, Puppeteer, or Playwright, and the act of attaching over the Chrome DevTools Protocol leaves traces independent of how perfect the fingerprint is. A page can probe for the side effects of an open CDP connection, and historically the Runtime.enable call left a particularly clean leak. A profile can present a flawless device and still be flagged because something is obviously driving it through the debugging protocol. The detail lives in the Chrome DevTools Protocol as a detection vector and detecting CDP in the wild, and the short version is that the anti-detect browser solves the “what device is this” problem while leaving the “is a human or a script in control” problem largely to the operator. The same point applies to the deeper truth that stealth plugins lose precisely because patching readable properties never closes the gap to a real Chrome’s full behavior; a forked browser closes more of that gap than an extension can, but not all of it.

The third seam is time. A fingerprint corpus ages. Real Chrome ships every few weeks, the population of real browsers shifts version by version, and a spoofed fingerprint frozen against last quarter’s corpus drifts slowly out of the real distribution. None of the vendors can fully escape this, because they are all chasing a moving reference, and the chase has a lag built into it: the detector sees the new real Chrome the day it ships, and the anti-detect vendor has to observe it, collect it, and ship a config update before its profiles match again. That lag is the structural disadvantage of impersonation, and it is why these tools are maintenance subscriptions rather than one-time purchases.

What actually separates them

Strip away the marketing and the four products line up on a small number of real axes. Multilogin is the only one that can hand you a different browser engine, which matters in the specific cases where presenting Firefox rather than a Chromium fork dressed as Firefox is the difference between blending in and standing out. GoLogin gives the most deployment flexibility, local, synced, or fully cloud-run, at the cost of deciding how much of your identity you are willing to host on someone else’s servers. Dolphin’s strength is the operational layer around the browser, the cookie-warming and multi-profile-synchronization tooling that treats a profile as something you cultivate over time rather than spin up cold, which is a tacit admission that the fingerprint is only half the disguise. Incogniton is the conventional, local-first, coherent-by-default option that does the standard things competently and the deep things less so.

But the axis that decides whether any of them works against a current commercial detector is the same for all four, and it is not engine or deployment or tooling. It is the quality and freshness of the real-device corpus the vendor copies from, and the discipline of never letting a user assemble a fingerprint that no real machine ever produced. The naive era of this technology, the canvas-noise-and-random-user-agent era, ended when detectors started checking relationships between values instead of values in isolation. Everything since has been an arms race over coherence, and coherence is not a feature you ship once. It is a corpus you have to keep re-collecting, against a reference browser that updates on a schedule you do not control. The 2025 result that no deployable defense against canvas fingerprinting exists is usually read as a loss for privacy browsers. It is equally a loss for the spoofers: the same statistical tools that strip Brave’s deterministic noise back out can pick a forked browser’s spoof out of a crowd, and the only profiles that survive that are the ones that were never noisy to begin with, just quietly wearing some other real machine’s face.

Sources & further reading

Further reading