Browser profiles and multi-account workflows

Practical guides · About 6 minutes

If you manage the same service for several clients, you've hit the wall: one login at a time, constant signing out and back in, and the low-level dread of having published something to the wrong account. The fix isn't a better memory. It's making the browser hold several identities at once.

Why one browser holds one login

A site knows who you are from a cookie scoped to its domain. One cookie jar means one identity per site — so signing into a second account overwrites the first.

Which points straight at the solution: give each identity its own cookie jar. Every technique below is a different way of doing that, trading isolation against convenience.

The options

Browser profiles

A full separate browser instance — its own cookies, storage, history, extensions, bookmarks, and saved passwords — in its own window.

Good: complete separation, available in every major browser, no add-ons needed. Each profile gets its own window, so you can label and position them. Extensions are per-profile, which means a client's required extension doesn't run everywhere else.

Less good: heavier on memory. Switching means changing windows. Ten clients means ten profiles, which becomes its own management problem.

Best for: a handful of long-running contexts — per client, or personal versus work.

Container tabs

Available in Firefox and by extension elsewhere: separate cookie jars within one window, with each tab colour-coded to its container.

Good: lighter than profiles and much faster to switch — different identities live side by side as tabs. The colour coding is genuinely valuable: the identity is visible before you click anything. Rules can pin a domain to always open in a specific container.

Less good: weaker separation than profiles (shared history, extensions, saved passwords), and browser-specific.

Best for: many identities on the same handful of services, where switching is frequent.

Multi-account support inside the service

Some platforms let one identity hold several accounts and switch between them natively — the account switcher in the corner.

Good: no browser gymnastics at all, and it's the vendor's supported path.

Less good: only exists where the vendor built it, and the switcher itself becomes the risk — one wrong click and you're acting as a different account with no visual difference beyond a small avatar. Where the platform supports proper delegated access instead, prefer that; see the client onboarding guide.

Private windows

Fine for a quick one-off second login. Everything is discarded on close, so it's not a workflow — but it saves setting up a profile for a five-minute task.

Separate browsers

Using different browser applications for different contexts. Crude but effective, and the strongest separation short of separate machines. Worth reserving for one specific case: keeping your highest-consequence accounts in a browser you use for nothing else. See below.

Make the identity visible

Isolation stops accounts leaking into each other. It does not stop you acting in the wrong one — for that you need to be able to tell them apart without thinking. Every mechanism here is worth the two minutes:

• Colour the profile or container. Both browsers and container extensions support a colour per context. Pick distinct ones and keep them stable; the colour becomes what you actually navigate by.
• Name it for the client, not the service. "Northwind", not "Ads account 2".
• Give each profile a distinct avatar or theme so the window is identifiable from the taskbar.
• Keep window positions consistent. Client A always on the left screen. Spatial memory is faster than reading.
• Use per-context bookmarks so each profile only contains links relevant to it. If the bookmark isn't there, you're in the wrong window.

The failure mode you're designing against isn't a hack. It's a Tuesday afternoon, three near-identical dashboards open, and one action taken in the wrong one. Colour and position prevent that; discipline doesn't.

Which credentials go where

Splitting the browser raises an obvious question: does the password manager get split too?

Generally no. Use one password manager account across all profiles, with per-client vault collections inside it. Splitting your vault by browser profile means several master passwords, several places to keep in sync, and a much higher chance something important lives in only one of them.

The exception is the Tier 1 browser. If you keep a separate browser for your highest-consequence accounts, it's reasonable for those credentials to be reachable only there — that's the isolation you were buying. Just make sure the recovery material is filed somewhere independent, per the break-glass guide.

Either way, disable the browser's own built-in password saving where you use a dedicated manager. Two vaults holding different subsets of your passwords is how entries drift out of date and how you end up unsure which copy is current.

Sessions still expire independently

Profiles don't change how long a site keeps you signed in — they multiply the number of independent sessions you're tracking. Three profiles against the same service means three sessions expiring on their own schedules, so you'll be logged out of one context and not another, which is confusing until you know to expect it.

Two things help. Note in your inventory which profile each account belongs to, so "where am I signed into this?" has an answer. And accept that batching logins per context beats trying to keep everything alive — the sessions guide explains why that's the winning approach.

Where this approach runs out

Worth being clear about the limits, because profiles get oversold as a security control.

They aren't a security boundary. All profiles run as the same operating system user with access to the same files. Malware on your machine reaches all of them. Profiles prevent sites from seeing each other's cookies; they don't defend against a compromised device.

They don't hide you from tracking. Cookies are separated, but browser fingerprinting and your IP address are not. If your goal is to prevent a service correlating two of your accounts, profiles alone won't do it.

They don't scale forever. Past roughly a dozen contexts, the profile switcher itself becomes the bottleneck. At that point container tabs, native account switchers, or a tool that manages the login sequence for you is a better answer than more windows.

Shared machines need real OS accounts. If someone else uses the device, a separate operating system user is the actual boundary. A browser profile is a convenience feature and won't stop anyone who wants to look.

Setting it up

1. List your recurring contexts — usually clients, plus personal and work.
2. Pick a mechanism: containers for many quick switches, profiles for fewer contexts needing real separation.
3. Create one per context, named for the client and given a distinct colour.
4. Sign into each context's accounts once, in the right window.
5. Add per-context bookmarks. Remove the ones that don't belong.
6. Set a separate browser aside for Tier 1 and use it for nothing else.
7. Record the profile in your inventory alongside each account.

An hour to set up, and it removes a daily irritation permanently — along with the category of mistake that's genuinely embarrassing to explain to a client.