Multi-Account Browser vs VPN: What Each One Actually Does

People often reach for a VPN to solve a problem it was never built for. A team member opens three client accounts in one browser behind a paid VPN with a kill switch and "military-grade encryption" in the marketing copy, and the sessions still end up tangled: the wrong client's login autofills, one client's cookies sit next to another's, the same saved passwords show up everywhere.

The VPN did exactly what it was sold to do. It hid the home IP from the sites at the far end and encrypted everything from the ISP. It just has no say over what the browser itself stores and reports.

That's the entire gap in one example.

The short version

A VPN protects where your traffic goes, from everyone between you and the destination, and shows a different IP to the site at the far end.

A multi-account browser keeps each profile's cookies, storage, proxy and identity parameters separate, so the accounts you are allowed to hold, and the teammates who share them, don't bleed into each other.

Two layers, two jobs. A VPN's adversary is your ISP, your employer's network, the router in the cafe. A multi-account browser's job is organisation and separation inside the browser. Buying more of one never gets you the other.

What a multi-account browser actually is covers the ground-up definition. This post is about the boundary.

What a VPN actually does

The list is genuinely short:

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

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

What grates is the marketing stacked on top. "Military-grade encryption" has meant approximately nothing since AES-256 became the default in everything down to your phone's lock screen. The overclaim is the real problem, not the product.

All of this 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 many subscribers through a small set of exit addresses. Both come back below.

What a VPN doesn't touch

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 report the output. Which fonts are installed. Screen width, height, colour depth, device pixel ratio. How many CPU cores. What's in navigator.

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. That's 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 two clients' accounts in the same browser and the two sessions sit side by side, no matter how many tunnels you stack. For client work this is the practical problem, and it's separate from fingerprinting. (JustAnalytics, our analytics product, has a plain-English write-up on how cookieless tracking works, written from the measurement side of the fence.)

Your TLS handshake is a fingerprint too. Before any JavaScript runs, your client offers a particular set of ciphers, extensions and curves. That set is characteristic of the 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 explains why those are two independent identifiers.

The exit-IP problem the ads skip

Here's the part that flips a VPN from neutral to unhelpful for some jobs.

A commercial VPN exit is a datacenter address: a hosting network shared by however many subscribers are on that server right now, and often on public lists of such ranges. Some sites treat those visitors differently, which matters for QA, ad verification and anything where you need to see what an ordinary visitor sees.

Our own proxy tester reports the fields a site could 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 you'll often see the hosting flag before you've loaded a page.

A residential or ISP address is a different purchase entirely; the ISP proxy setup walkthrough covers the static-IP flavour. And plainly: the subscription doesn't include proxies or bandwidth. Bring your own or buy a proxy plan in the app, and assign it per profile.

Multi-account browser vs VPN, side by side

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

Four ways a VPN-only setup gets messy

Timezone against exit country. The browser reports America/Chicago while the exit IP resolves to Amsterdam. Localized pages, currency and ad targeting then disagree with each other, which is confusing for QA and for ordinary browsing. Checking takes thirty seconds.

One browser, many clients. One Chrome install, one cookie jar, every client's logins in the same place. The VPN never enters 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 shows a resolver in one country and an exit in another. The DNS leak and proxy resolution guide has the whole failure mode. The fixes are 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 the exception list quietly becomes a leak list nothing audits. Then the tunnel drops for a few seconds during a server hop and your real address lands in someone's log. The kill switch that would have caught it is usually two toggles away and off by default.

What the multi-account browser layer actually does

JustBrowser is built on a custom Chromium engine with native C++ integration, patched with every upstream Chromium release. Identity parameters are applied by the engine at the canvas / WebGL / audio / font / screen layer, across 40+ parameters. It isn't an extension and it isn't a JavaScript overlay.

The distinction matters for consistency. A script injected into the page has to override the real answer, and that can leave inconsistencies between the main page, workers and other APIs. A value set in the engine is the value every API reports.

One specific, because it gets guessed at constantly: the font list is restricted to the chosen platform's set at the engine level, covering CSS enumeration, the Font Access API and @font-face local() together.

On top of that: per-profile proxy routing (HTTP, HTTPS, SOCKS5), per-profile DNS-over-HTTPS, WebRTC protection, shared profiles with role-based permissions (owner, admin, member, viewer), and a local REST API for your own automation. The glossary of fingerprinting terms names the rest of the vocabulary.

You can check the privacy side yourself: open a profile on BrowserLeaks and confirm that WebRTC exposes no address other than your proxy's, and that timezone, language and platform agree with the exit IP.

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

This comparison usually gets written by people with something to sell, so plainly:

If what you want is privacy from your ISP, safety on public wifi, or a different region for casual viewing, buy a VPN. We don't do any of that. JustBrowser isn't a system-wide tunnel and it doesn't encrypt traffic outside the profiles you run.

A few more limits. Windows x64 and macOS on Apple Silicon only. There's no Linux build, so "run it on a VPS" isn't a path. The REST API is bound to 127.0.0.1: local, not hosted, with nothing to call at an api. subdomain. No iOS or Android app.

We're one plan at $9.99/month or $99.99/year with unlimited profiles and free team seats. It's simple, but there's no free tier beyond the 7-day trial, and the trial needs a card.

Where the browser layer earns its place: agencies working in client accounts they have been given access to, storefronts you operate, QA across device and locale combinations, ad verification across geographies, and automation through Playwright, Puppeteer or Selenium for your own workflows. Where a platform limits you to one account or restricts one, that is a rule for you to follow and an appeal route to use, and no browser setup changes it.

Running both, in the right order

1. Decide which layer is the problem. Slow or blocked network access is a network question. Tangled sessions are a browser question. Diagnose before you buy.
2. Sort the address first and test it alone: exit IP, reputation, the proxy and hosting flags.
3. Create the profile and 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. Open a test page such as BrowserLeaks to confirm the profile reports one consistent location, then read the rules of any platform you use before you sign in to anything.

Step 4 gets skipped because it feels like paperwork, and it's the one that causes the most confusing results.

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 machine-level configuration. Every profile on that computer 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. Incognito clears state at the end of a session but changes nothing about identity during it.

Is a multi-account 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 a multi-account 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 its own cookies, storage and identity parameters. Different job.

Why does my work still mix together even though I use a different VPN server for each client?

Because the IP was never the only thing shared. Different exit IPs don't separate anything if every client's work lives in the same browser: the same cookie jar, local storage, saved logins and extensions. A VPN separates where traffic appears to come from. A profile separates what the browser remembers. For client work you are permitted to do, you usually want the second one.

---

Try JustBrowser

A multi-account browser for teams, on a custom Chromium engine always current with upstream, not an extension. Real C++ engine patches at the canvas / WebGL / audio / font / screen layer, so each profile's 40+ identity parameters are consistent. Local REST API + CDP for Playwright, Puppeteer, Selenium. Windows x64 and macOS (Apple Silicon). One plan: $9.99/month or $99.99/year — unlimited profiles, free team seats, 7-day free trial, card required.

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