Multi-Account Browser Isolation: Independent Identity Settings
Learn which signals link accounts, how contexts and separate instances differ, and how to check that each identity has its own route, fingerprint settings, and storage.
BotBrowser Team
Prefer the maintained product doc?
This article has a matching page in the docs center. Use the docs for the canonical setup flow, current flags, and long-term reference.
Five signals that can link one account to another
Anyone who operates several accounts on purpose, such as an agency that manages client pages, a support team that reproduces regional issues, or a researcher who compares localized content, runs into the same problem: the accounts share more than the person behind them. A site does not need a name to notice that two sessions have something in common. It only needs a few values that repeat. Isolation work is therefore a matter of deciding which values must stay independent for each identity and making sure each one is set on purpose instead of being inherited by accident from the machine. The advice below assumes that every account is yours, or is operated with its owner's permission and within the platform's terms.
Five dimensions matter in practice. They are listed in the order in which they usually cause trouble.
- Network route. Two accounts that sign in from the same IP address are easy to connect. Each identity needs its own approved route, and the route should come from a provider you have vetted.
- Fingerprint signals. Rendering output for Canvas and WebGL, audio characteristics, screen dimensions, and navigator values come from the hardware and the operating system, so they repeat across everything that runs on one machine unless something changes them.
- Cookies and storage. Cookies, localStorage, IndexedDB, cache, and service workers hold state. Any sharing here links accounts directly, without any inference.
- Geographic metadata. Time zone, locale, and language should agree with each other and with the route. An account that appears to sign in from Berlin while reporting a New York time zone is inconsistent with itself.
- Activity timing. Accounts that always start, pause, and act at the same moments from the same machine form a pattern that no browser setting can remove.
The first four are configuration questions, and a browser can help with them. The fifth is about how people and schedules behave, which is why it appears below as an operating habit rather than a setting.
Keep one idea in mind for the rest of the discussion: isolation reduces linkability across these dimensions, and it never reduces it to zero. A well-configured set of identities removes the cheap, accidental connections. It does not stop a determined analyst from correlating accounts through behavior, shared payment details, or the way the same person writes. Planning with that limit in mind produces better decisions than assuming perfect separation.
Independence is only half of the goal; each identity must also be consistent with itself. A profile that describes a desktop device, a locale that belongs to another country, and a route in a third region make one identity look contradictory, which is a signal in its own right. When you set up an identity, ask two questions: is it different from the others on every dimension, and do its own settings describe one coherent device in one coherent place? Both answers need to be yes.
One instance with several contexts, or several instances
Chromium-based browsers separate storage by browser context. Playwright describes a context as an isolated browser session: each one has its own cookies, local storage, IndexedDB data, cache, and service workers, and a test can open many of them inside a single browser at a low cost. That is standard behavior and it does not depend on any special build. It covers the third dimension in the list above, and it is the reason a context is the natural unit for one identity.
What a standard context does not separate are the signals that come from the hardware and the operating system. Rendering output, audio characteristics, screen dimensions, and navigator values are identical in every context of an ordinary browser, because every context runs on the same machine. A stock setup therefore gives you storage isolation and nothing more. Firefox containers and separate user data directories share the same boundary: cookies are kept apart, while the signals that come from the device stay the same.
Heavier options exist at the other end of the scale. Separate browser installations and virtual machines give strong separation, since each has its own binaries, operating system, or hardware profile, but they multiply the work of updating, monitoring, and storing every environment, and each virtual machine reserves memory for a whole operating system. They suit cases where compliance rules demand that identities share no host at all. For most multi-account work, contexts and separate browser instances cover the need at a lower operating cost.
Two layouts are common. In the first, one browser instance holds several contexts, each assigned to one identity. It starts quickly, shares the cost of the instance, and uses less memory per identity. BotBrowser's per-context fingerprint feature was designed for this layout: each context can carry its own profile, time zone, locale, noise seed, and proxy, and the documentation lists most BotBrowser command-line flags as supported per context. That feature requires the ENT Tier3 license, so confirm your license tier before you design around it.
In the second layout, every identity gets its own browser instance with its own profile file and its own user data directory. Nothing is shared between instances, which gives the cleanest separation and the simplest explanation for an auditor. The price is cost: each instance has its own startup time and memory use, and the number of instances a machine can hold is limited by its hardware rather than by the browser. A crash or a stuck page also affects only one identity, which is a real operational advantage.
Choose by risk and by volume. If identities are few and the cost of a mix-up is high, separate instances are easy to reason about. If you need many identities on limited hardware, one instance with several contexts is more efficient, provided you accept that the contexts share a browser instance and rely on the per-context settings for everything else. Many teams use both: contexts inside each instance for related identities, and separate instances for groups that must never share infrastructure. Whichever layout you choose, give every instance its own user data directory so that profile data never collides.
Capacity is a measurement, not a promise. How many identities one machine can carry depends on available memory, processor cores, and how heavy the pages in each context are, so test with your real workloads instead of copying a number from someone else's setup. Browser Context Capacity Planning shows how to plan and watch resource use as the number of contexts grows. Add identities gradually, watch memory and page load times, and stop when the machine starts to slow down.
Assigning independent settings to each identity
Start with a plain record of identities before you touch any configuration. For each one, write down the profile file, the route, the time zone, the locale and languages, the noise seed, and the data directory or context that holds its state. The record is short, but it prevents the most common failure: reusing a value because it was already on the command line. Treat each row as a unit that does not share a value with any other row, except where you have decided that sharing is acceptable.
The profile sets the base fingerprint. Separate profile files give the strongest separation because each one describes a different device, while one profile combined with different noise seeds gives different output from the same base. The noise seed controls small variations in rendering and audio output. The same seed always produces the same result, so an identity stays stable between sessions, and a different seed gives another identity a different result. Pick the seed once, store it with the identity record, and do not change it without a reason. Noise Seed Reproducibility covers the details.
The route and the geographic metadata must agree. When you assign the proxy to a context through its BotBrowser settings, BotBrowser derives the time zone, locale, and language from the exit address of that route. The documentation also lets you supply the exit address yourself, which skips the lookup and speeds up context creation. It warns that a proxy set only through Playwright's built-in option leaves the time zone out of step with the route, so use the BotBrowser --proxy-server setting for per-context routes. Explicit time zone, locale, and language values remain available when you need to override the derived ones, as described in Timezone, Locale, and Language Configuration.
Stability over time is part of the design. An account that keeps the same profile, seed, route region, and data directory from one session to the next looks like one person returning to one device. An account whose settings change from session to session looks like several devices, and it can trigger extra verification on platforms that watch for new devices. If an identity needs a new route, such as after a provider change, keep the region and the geographic metadata steady and update the record. Change the profile or the seed only when you intentionally retire the identity.
Order matters inside one instance. The per-context settings must be applied after the context exists and before its first page opens, because a page reads them when it starts, and settings applied to a context that already has a page do not take effect. Workers created from pages in that context, including dedicated, shared, and service workers, inherit the context's identity, so they need no extra step. Create each context, apply its settings, and only then open pages.
Route details deserve their own care. Give each identity a separate approved route, and check how your provider and the browser handle DNS and WebRTC so that the route you chose is the one that carries every connection. BotBrowser documents controls for both on the network side, and Per-Context Proxy explains how to assign and validate routes by context. Keep the credentials for each route in a secret manager instead of in scripts that several identities share.
Checking each identity separately
Verification means reading back observable values for each identity and comparing them with your record. Do it after every configuration change and whenever the browser release changes. Use a test page that you control or a neutral public page, and keep the checks short. The aim is to confirm that your settings reached each context, not to study how a particular website works. Run the same checks in every identity so that the results can be compared line by line.
- The public IP address differs between identities and matches each assigned route.
- The reported time zone, locale, and language match the region of that route.
- Canvas rendering output differs between identities that use different profiles or noise seeds.
- The WebGL renderer string differs between identities that use different profiles.
- Cookies and storage written in one identity are absent from every other identity.
Interpret the results with the right expectations. Differences in the renderer string are expected from separate profiles, while noise seeds mainly change rendering output, so two identities on one profile can legitimately report the same renderer string. If an expected difference is missing, look at the record first: a repeated seed, a shared profile file, or a context whose settings were applied after its first page are the usual causes, and a shared data directory explains shared storage.
Keep the checks apart from the identity's normal sessions. Open the verification page in a fresh page of the same context, record the values, and close it, so that a check does not leave extra state in the account's storage, history, or timing. Do not sign in to anything or load pages that belong to the real account during a check. Store the recorded values with the identity record so that a later change can be compared with them.
Schedule the checks. Run them when you create an identity, after any change to a profile, route, or seed, after a browser update, and on a regular calendar for long-lived identities, such as once a month. A short, repeatable checklist is more useful than a long one that nobody finishes. When a value changes without a matching entry in the record, treat it as a finding: find out who changed what, and correct either the configuration or the record before the identity is used again.
Remember what a passing check means. These readings confirm that settings were applied as intended and that identities are distinct on the values you read. They do not prove that a particular site cannot connect two identities, because a site can use signals you did not read, and because linkage can come from behavior rather than from browser values. Treat a clean result as evidence that the configuration is correct, never as a guarantee about how any platform will behave.
What browser settings cannot cover
Timing is the first gap. Accounts that always act in the same minutes, sign in right after one another, or follow identical routines present a pattern that has nothing to do with the browser. Stagger schedules, vary how long sessions last, and let each account follow the rhythm that suits its purpose. Do not drive several accounts from one script that runs them in lockstep.
The second gap is shared material. The same email address, phone number, payment method, recovery contact, or uploaded file ties accounts together at the platform level. Cookies deserve special mention: copying a cookie from one identity into another carries the session and its identifiers with it, and undoes the separation that storage isolation provides. Never move cookies, exported sessions, or saved passwords between identities.
Routine hygiene covers the remaining gaps. Close contexts that are finished so that memory is released and state does not accumulate. Use persistent data directories only for identities that must keep state between runs, with one directory per identity. Keep route credentials, profile files, and seeds in access-controlled storage with a named owner. Read the terms of every platform you use: some platforms limit the number of accounts one person may operate, and no browser configuration changes those rules or the way the platform enforces them.
Plan for mistakes, because they will happen. If a cookie was copied by hand, a profile file was reused, or two contexts were opened with the same settings, treat both identities involved as mixed. Stop using them for the affected work, document what happened, and rebuild the affected identity with a fresh data directory and its own settings instead of patching it in place. Rebuilding is slower in the moment, but it leaves a record that is easy to trust, whereas a patched identity keeps whatever state leaked into it.
Before you add a new identity, review it against the five dimensions and against the shared material above. Does it have its own route, its own profile and seed, its own data directory, its own schedule, and its own set of account details? A new identity that fails any of these questions is not yet isolated, even if the browser settings are correct.
BotBrowser supports assigning a separate profile, proxy, time zone, locale, and noise seed to each BrowserContext within one browser instance (per-context fingerprint requires the documented ENT Tier3 license), or running separate instances with their own profiles and user data directories, so that each identity presents independent fingerprint and network settings and you can keep accounts apart without maintaining a full set of machines. BotBrowser cannot guarantee that accounts will never be linked: it does not supply proxies or IP reputation, it does not control behavioral or timing correlation, how you handle cookies, or a platform's account policies, and it does not replace sound operational separation of accounts.
Public sources
Related Articles
Take BotBrowser from research to production
The guides cover the model first, then move into cross-platform validation, isolated contexts, and scale-ready browser deployment.