JustBrowser
Guides13 min read

Antidetect Browser vs VPN: What Each One Actually Hides

JustBrowser Platform Team·
antidetect-browservpnbrowser-fingerprintingip-addressmulti-accountingbuildinpublicsaasstudioaiworkforcebuildwithclaude

Someone posted this in an e-commerce forum a few weeks back. Paid VPN, top tier, kill switch on, "military-grade encryption" in the marketing copy. Three marketplace accounts opened across four months, all three suspended inside about ninety minutes of each other on a Tuesday morning. No antidetect browser anywhere in the setup — which turned out to be the whole story.

Every reply said the same thing: get a better VPN.

Which is a bit like replacing your tyres because the engine won't start. His VPN was working exactly as sold. It hid his home IP from the marketplace, encrypted everything from his ISP, and did both flawlessly — and then his browser walked up to the door and introduced itself by name. Three times. In the same voice.

I'd love to say I spotted that immediately. I didn't. My own version ran three weeks, most of it spent blaming a proxy vendor who'd done nothing wrong, and it ended with an apology email I still think about.

That's the entire gap in one story.

The short version

A VPN hides where your traffic is going, from everyone between you and it — and hides your home IP from the site at the far end.

An antidetect browser changes what your browser says about itself once the connection is open.

Two layers, two threat models. A VPN's adversary is your ISP, your employer's network, the router in the café. An antidetect browser's adversary is the fingerprinting script the destination site runs the moment the page loads. Buying more of one never gets you the other.

What an antidetect browser actually is covers the ground-up definition. This post is about the boundary.

What a VPN actually hides

The list is genuinely short:

  • Your real IP from the destination. The site logs the VPN's exit address instead.
  • Traffic contents and destinations from your local network. Your ISP, the hotel wifi, a corporate proxy — they see an encrypted tunnel to one endpoint and nothing about what's inside it.
  • Coarse geography. Pick an exit country, get that country's GeoIP answer.
  • DNS lookups, sometimes. A well-built client pushes resolution through the tunnel. A badly built one leaves it on your own resolver, which quietly undoes half the point.

That's the surface. Four bullets, all of them worth paying for.

What grates is the marketing stacked on top. That military-grade encryption line from the forum post has meant approximately nothing since AES-256 became the default in everything down to your phone's lock screen. I think the overclaim is the real root cause here. Not the product — the promise.

Anyway. All of it sits below the application — the same layer a proxy works on, with two differences that matter here: a VPN is usually system-wide rather than per-application, and a consumer VPN funnels thousands of subscribers through a small set of exit addresses.

Hold both of those. They come back.

What a VPN doesn't touch, at all

Tunnel's up, page loads, and the site starts asking your browser questions. Hundreds, if the script is any good.

Draw this shape on a canvas and hash it. What vendor and renderer string does WebGL report. Run an oscillator through an audio graph and tell me the output. Which fonts are installed. Screen width, height, colour depth, device pixel ratio. How many CPU cores, how much memory. What's in navigator. What's navigator.webdriver.

None of those answers go anywhere near the VPN. They're generated locally, by your browser, from your actual machine, and handed over on request. The tunnel carries them faithfully and has no mechanism to rewrite them — not a flaw, just not in the job description.

Two consequences people don't expect:

Your cookie jar is shared. One browser means one storage layer: cookies, localStorage, IndexedDB, service workers, cached tokens. Log into account A and account B in the same browser and you've handed over a direct link that no tunnel touches. This is separate from fingerprinting and it catches people who did everything else right. (JustAnalytics, our analytics product, has a plain-English write-up on how cookieless tracking works — useful precisely because it's written from the measurement side of the fence.)

Your TLS handshake is a fingerprint too. Before any JavaScript runs — before the page exists — your client offers a particular set of ciphers, extensions and curves in a particular order. That shape is stable per client build and it survives the tunnel completely, because the tunnel carries the handshake rather than reshaping it. ClickzProtect, our sibling product, works the detection side; its breakdown of browser versus TLS fingerprinting is the clearest explanation I've seen of why those are two independent identifiers.

The exit-IP problem the ads skip

Here's the part that flips a VPN from neutral to actively unhelpful.

A commercial VPN exit is a datacenter address. Hosting ASN, shared by however many subscribers are on that server right now, on every public flag list for years. It isn't an anonymous IP. It's an IP that announces what it is.

Our own proxy tester reports the same fields a site would look at: exit IP, ISP or organisation name, country, city and timezone, latency, a reputation score with blocklist hits, and three flags for proxy, hosting and mobile. Point it at a consumer VPN exit and watch two of those three light up before you've loaded a single page.

Some sites don't care. Marketplaces, ad platforms and payment flows care a lot. A residential or ISP address is a different purchase entirely — the ISP proxy setup walkthrough covers the static-IP flavour. And plainly: we don't sell proxies or bundle bandwidth. Bring your own, assign it per profile.

Antidetect browser vs VPN, side by side

What the site can checkVPN changes it?Antidetect browser changes it?
Exit IP addressYesNo — routes through the proxy you supply
ASN / hosting flagYes, usually for the worseNo
Canvas, WebGL, audio outputNoYes — C++ patches in the engine
Installed font listNoYes — gated to the spoofed platform's set
Screen size, colour depth, DPRNoYes
navigator properties, navigator.webdriverNoYes
Cookies, localStorage, IndexedDBNoYes — isolated per profile
Timezone reported by JavaScriptNoYes — set per profile
DNS resolver locationSometimesYes — per-profile DNS-over-HTTPS
WebRTC address exposureSometimesYes
Encrypting traffic from your ISPYesNo

Look at that last row. It's the one honest argument for a VPN here, and it's a real one.

The four ways a VPN-only setup gets caught

Timezone against exit country. Browser reports America/Chicago, exit IP resolves to Amsterdam. Nobody lives like that. I'd guess it's the most common own-goal in the category — nobody publishes numbers, so that's a guess — and checking takes thirty seconds.

One browser, many accounts. The forum post. One Chrome install, one canvas hash, three suspensions. The VPN never entered into it.

Side doors. WebRTC can surface local and public addresses over a path that ignores the tunnel, and DNS can leak to your own resolver — which hands the site a resolver in one country and an exit in another. The DNS leak and proxy resolution guide has the whole failure mode. Fixes: per-profile DNS-over-HTTPS in secure or automatic mode, pointed at Cloudflare, Google, Quad9 or a resolver you choose, plus WebRTC protection.

Split tunnelling and the reconnect gap. Most clients let you exempt applications from the tunnel, and approximately nobody remembers six months later what they exempted or why — so the exception list quietly becomes a leak list nothing audits. Then the tunnel drops for four seconds during a server hop and your real address lands in someone's log with your session cookie attached. Four seconds. That's the whole event.

Honestly, this one annoys me, because the kill switch that would have caught it was two toggles away and off by default.

What the antidetect browser layer actually changes

JustBrowser's approach is C++ compiled into a custom Chromium core — real engine patches at the canvas / WebGL / audio / font / screen layer, across 40+ identity parameters, on a core patched with every upstream Chromium release. Not an extension, not a JavaScript overlay.

The distinction is more than marketing, and this is the hill I'll die on. An injected script has to lie on top of the real answer, and that leaves a seam: the override is enumerable, the prototype chain looks wrong, the timing is measurably off. A patch in the core has no real answer underneath it to contradict.

Put it this way. One approach edits the transcript after the interview. The other changes what the person says.

Two specifics, because both get guessed at constantly. navigator.webdriver returns false — not undefined, false, patched unconditionally whether or not automation flags are set. And the font list is restricted to the spoofed platform's set at the engine level, covering CSS enumeration, the Font Access API and @font-face local() together. Not a filtered array a determined enumerator can walk around.

On top of that: per-profile proxy routing (HTTP, HTTPS, SOCKS5), per-profile DNS-over-HTTPS, WebRTC protection, and cookie warm-up across 127 curated sites in six categories, for accounts that need to look lived-in, not born yesterday. The detection signals glossary names the rest of the vocabulary.

Verification numbers we publish: CreepJS 0% stealth and 0% headless, Whoer 90–100%, IPHey Trust "Good", BrowserLeaks no WebRTC leak. Test your own setup against those rather than taking anyone's word for it, ours very much included — I've watched vendors screenshot a passing result from a machine that wasn't running their product, and a blog post can't prove we're not doing the same. Go run it.

When a VPN is right and we're the wrong purchase

Real talk, because this comparison usually gets written by people with something to sell.

If what you want is privacy from your ISP, safety on public wifi, or access to content that's geo-restricted for casual viewing — buy a VPN. We don't do any of that. JustBrowser isn't a system-wide tunnel, it doesn't encrypt traffic outside the profiles you run, and pointing it at a Netflix library is an expensive way to solve a cheap problem.

A few more honest limits. Windows x64 and macOS on Apple Silicon only — there's no Linux build, so "run it on a VPS" isn't a path, and better you hear that now than in week two. The REST API is bound to 127.0.0.1: local, not hosted. Nothing to call at an api. subdomain, no story where your CI runner reaches it over the internet. No iOS or Android app.

And we're one plan at $9.99/month or $99.99/year with unlimited profiles and free team seats — simple, but it does mean there's no free tier to poke at beyond the 7-day trial, and that trial wants a card.

Where the browser layer earns its place: multiple accounts on one platform, scraping a JavaScript-heavy app that challenges you, ad verification across geographies, QA across device and locale combinations, automation through Playwright or Selenium where the fingerprint holds up under a driver.

Running both, in the right order

  1. Decide which layer is actually failing. IP-based rate limiting is a network problem. A challenge page on a clean, unused address is a client problem. Diagnose before you buy.
  2. Get the address sorted first and test it alone — exit IP, reputation, the proxy and hosting flags. A flagged address poisons everything downstream.
  3. Create the profile, assign that address to it. One address, one profile.
  4. Match timezone and language to the exit geography before the first page load.
  5. Turn on WebRTC protection and per-profile DNS-over-HTTPS.
  6. Verify against the checkers — then load a few real pages on the target platform before you register anything. The challenge you'll hit at signup is one you can trigger for free while nothing's at stake.

Step 4 gets skipped because it feels like paperwork. It's the one that gets people. I've skipped it myself, more recently than I'd like to admit in a post I'm publishing under the company name.

Frequently Asked Questions

Does a VPN stop browser fingerprinting?

No, and it isn't built to. A VPN encrypts your traffic and swaps the IP the site logs. Fingerprinting happens after that, in JavaScript running inside your browser — canvas rendering, WebGL renderer strings, audio output, installed fonts, screen geometry, navigator properties. Those answers are generated locally on your real machine and handed over on request. The tunnel carries them; it never rewrites them.

Can I just use a VPN with separate Chrome profiles or incognito windows?

Separate Chrome profiles do split cookies and local storage, which is genuinely useful. What they don't split is the fingerprint. Every profile on that machine renders the same canvas, reports the same GPU string, lists the same fonts and reports the same screen geometry — and with a VPN they all leave through one exit IP too. So you get identical machines on one address, which is the pattern a linking system is specifically looking for. Incognito is worse: it clears state at the end of a session but changes nothing about identity during it.

Is an antidetect browser a replacement for a VPN?

Not for what most people buy a VPN for. If your goal is keeping your browsing private from your ISP, your employer's network or a hotel router, a VPN does that and an antidetect browser does not — it isn't a system-wide tunnel and it doesn't encrypt anything outside the profiles you run. JustBrowser routes each profile through a proxy you supply and gives each one a distinct identity. Different job.

Why did my accounts get linked even though each one used a different VPN server?

Because the IP was probably never the link. Different exit IPs don't help if the accounts share a browser — same canvas hash, same renderer string, same font set, same screen geometry, and often the same cookie jar and local storage. A shared browser is a stronger identifier than a shared address, and it's harder to spot because the network side looks clean. Check the fingerprint before you buy more VPN servers.


Try JustBrowser

Antidetect browser on a custom Chromium engine, always current with upstream — not extension-based. Real C++ engine patches at the canvas / WebGL / audio / font / screen layer, so 40+ identity parameters are genuine, not faked. Local REST API + CDP for Playwright, Puppeteer, Selenium. One plan: $9.99/month or $99.99/year — unlimited profiles, free team seats, 7-day free trial.

Get started → · How it differs from Multilogin / GoLogin / AdsPower

Ready to manage multiple accounts?

Seven days free, then $9.99/month — one plan, everything included.

We'd like to use Google Analytics, a Google service, to understand how our website is used. It sets two cookies in your browser and runs only if you click Accept. You can change your choice at any time with Cookie settings. Cookie Policy

Sign-in cookies and the cookie that remembers this choice are always on; the website needs them to work.

Google Analytics, a Google service, helps us understand how our website is used. It sets two cookies, _ga and _ga_TVZHQ99TZW. It is now onoff in this browser. If your browser sends a Global Privacy Control or Do Not Track signal, it stays off. Cookie Policy