Antidetect Browsers: What They Actually Do Under the Hood

Got into an argument on Telegram last week. Someone was saying antidetect browsers are "just Chrome with a skin" and that you're paying $100/month for something you could do with Firefox profiles.

He's wrong. But also kind of right? Let me explain.

What "antidetect" actually means

The word gets thrown around a lot. GoLogin, Multilogin, AdsPower, Dolphin - they all call themselves antidetect browsers. Marketing teams love the word. But what does it mean technically?

At the core, every antidetect browser does two things:

1. Creates isolated browser profiles (separate cookies, storage, extensions)
2. Spoofs browser fingerprint parameters so each profile looks like a different machine

The first part is easy. Chrome can do that natively. Firefox has containers. You can literally just create a new Chrome profile and get isolation.

The second part is where it gets interesting. And where most tools either shine or completely fall apart.

The fingerprint stack

When a website wants to identify you, it doesn't just check one thing. It builds a stack. I'm gonna walk through the layers because understanding this is the only way to evaluate whether an antidetect tool is actually working.

Layer 1: The obvious stuff

User agent, screen resolution, language, timezone. The things you can check in browser settings. Every antidetect tool handles these. If yours doesn't, that's not an antidetect browser, that's just Chrome.

Layer 2: Canvas and WebGL

This is where it gets real. Your browser can be asked to draw things - render text, shapes, gradients. The output differs slightly between machines because of GPU differences, driver versions, font rendering. Sites hash the output and use it as an identifier.

WebGL goes deeper. It exposes your GPU vendor and renderer strings. ANGLE (NVIDIA GeForce RTX 3070 Direct3D11 vs_5_0) - that kind of thing. Pretty unique.

Spoofing these requires injecting noise into canvas operations and replacing WebGL parameter strings. Sounds simple. It's not.

Layer 3: Audio fingerprinting

Yeah, this is a thing. Sites create an AudioContext, run a signal through an oscillator and compressor, and measure the output. Different hardware produces different results. Tiny floating-point differences that create a unique hash.

Most people don't even know this exists. Some antidetect tools don't handle it either.

Layer 4: WebRTC

Designed for video calls, leaks your real IP and local network info. Even through a VPN. I've seen people set up elaborate proxy chains and then leak their home IP through WebRTC because their antidetect tool forgot about it.

Layer 5: Client Hints and the new stuff

Chrome has been pushing User-Agent Client Hints as a replacement for the user agent string. navigator.userAgentData returns structured data about your browser, platform, architecture, bitness. Most antidetect tools from 2023 or earlier don't spoof this at all. Sites are starting to check it.

Where most antidetect browsers fail

Okay here's the part where I might upset some people. Been testing these tools on and off for a couple years. The biggest problem isn't missing features - it's consistency.

The consistency problem

Say your antidetect profile claims to be a MacBook. User agent says macOS. Screen is 2560x1600. Retina display, so devicePixelRatio is 2. All good so far.

But then:

• Font list shows Calibri and Segoe UI (Windows fonts)
• WebGL renderer says ANGLE with Direct3D (Windows-only)
• Platform reports "Win32"

Any detection system checking for consistency flags this immediately. You're not just "not anonymous" at this point - you're actively suspicious. A detection system now knows you're using spoofing tools, which is arguably worse than just having a matching fingerprint.

I tested one popular tool (not naming names) that spoofed the timezone to Asia/Tokyo but left the locale as en-US and the system fonts as a standard Western European set. That's like wearing a fake mustache while holding your real ID.

The Worker blind spot

This is a technical thing but it matters a lot.

Modern websites run JavaScript in Web Workers - separate threads that don't share the main page's context. If your antidetect only patches the main thread, a site can spin up a Worker, call navigator.hardwareConcurrency or run canvas operations there, and get your real fingerprint.

Same goes for Service Workers and Shared Workers. And Blob URLs - sites can create a Blob containing JavaScript, create a Worker from it, and run fingerprint checks there. If the antidetect tool doesn't intercept Blob creation and inject spoofing code... real values leak.

This is not hypothetical. CreepJS and other advanced detection tools specifically test this. Go run your antidetect profile against CreepJS and check the Worker results. You might be surprised.

The iframe problem

Similar to Workers. Sites embed iframes from different domains. If your spoofing doesn't propagate into iframe contexts, the iframe sees real values while the parent sees spoofed ones. Mismatch = detected.

Some antidetect tools intercept HTMLIFrameElement.prototype.contentWindow to inject spoofing into new iframes. Others don't bother.

What good antidetect looks like

After all the complaining, here's what actually works:

Early interception. Spoofing code needs to run before anything else on the page. If a site saves a reference to the original navigator.hardwareConcurrency before your spoofing kicks in, game over. The injection needs to happen at document_start, before any page scripts execute.

Multi-layer spoofing. Canvas and WebGL can't be patched at just one level. You need prototype-level overrides, instance-level patches on context creation, and coverage for OffscreenCanvas (which Workers use). Miss one layer and detection finds the gap.

Deterministic noise. Canvas spoofing often works by adding random noise to pixel data. Problem: if every page load produces a different canvas hash, that's detectable too. Real browsers produce consistent hashes. Good antidetect uses a seed-based approach - same seed always produces the same noise, so your fingerprint is unique but stable.

Automation marker removal. Selenium, Puppeteer, Playwright - they all leave traces. navigator.webdriver, ChromeDriver markers like $cdc_ variables, the window.chrome structure being wrong. Detection systems check for these. A lot of antidetect tools forget to clean them up because they assume you're a human user, but some fingerprint tests check regardless.

Coherent profiles. Every parameter needs to tell a consistent story. If you say you're on Windows 11 with an NVIDIA GPU, your fonts, WebGL strings, platform, Client Hints, and screen metrics all need to match that story. This means the fingerprint generator needs to understand which combinations are realistic.

The $100/month question

Most antidetect browsers charge between $50-$300/month. For that you get the browser itself plus cloud profile syncing.

Here's what I think about that pricing. The fingerprint spoofing tech is not rocket science. It's meticulous, yeah. Lots of edge cases with Workers and iframes and Client Hints. But it's deterministic work - you intercept APIs and return different values. The code doesn't need a server, it runs locally.

What you're actually paying for with cloud-based antidetect is convenience and profile syncing. The spoofing itself could be a browser extension. Some open-source projects have proven this.

The reason most people pay is because setting it up yourself is tedious. And fair, your time has value. But if you're already using a tool that manages browser profiles and wallets, adding fingerprint protection as a built-in feature makes more sense than paying separately for a standalone antidetect browser.

Testing your setup

Whatever tool you use, test it. Don't trust marketing pages.

Step 1: Open two different profiles. Go to a fingerprint testing site. Every single parameter should differ - canvas hash, WebGL renderer, audio fingerprint, screen size, timezone, everything. If you see matches, your spoofing is broken.

Step 2: Check Worker consistency. Sites like reviewer.eugenebos.com test both main thread and Worker fingerprints. They should match within each profile and differ between profiles.

Step 3: WebRTC leak test. If your real IP appears anywhere, stop what you're doing and fix it. This is the most common leak I see.

Step 4: Check Client Hints. Open DevTools, go to Console, type navigator.userAgentData.getHighEntropyValues(["platform", "platformVersion", "architecture", "bitness", "fullVersionList"]). The values should match your spoofed profile, not your real machine.

Step 5: Run CreepJS. It's the hardest test out there. You probably won't get a perfect score - nobody does. But your main thread and Worker results should be consistent with each other. If main thread shows spoofed values but Workers show real ones, you have a blind spot.

So what's the point

Look, you can use separate Chrome profiles and call it a day. For basic stuff - separating personal browsing from crypto - that's honestly fine.

But if you're running multiple wallets, farming protocols, or doing anything where identity separation actually matters, you need real fingerprint isolation. Not just different cookies - different fingerprints that look like different machines.

The antidetect browser market is full of tools charging subscription fees for what should be a basic feature of any multi-wallet management setup. Understanding what's happening under the hood helps you evaluate whether you're getting actual protection or just a fancy Chrome wrapper.

Don't trust the marketing. Test it yourself. If a tool can't pass basic fingerprint consistency checks, it doesn't matter how pretty the UI is.

---

Not financial advice, not security advice, just a guy who's spent too much time reading browser API specs. Do your own testing.

Related: How browser fingerprinting works and why separate profiles are the minimum for crypto security.