Isolated tabs, and why each account needs its own

The request sounds simple. One window, several tabs, and each tab signed in as a different account. No second browser, no second profile, no logging out. It is a reasonable thing to want, and on a Mac it is partly possible today. The part that is possible is narrower than most articles suggest, and the part that is missing is not a feature gap so much as a mismatch between what a tab is and what an account is.

What follows is what a tab can actually hold on its own, which of the three isolation mechanisms available on macOS draws the boundary where, and how to tell when the tab has stopped being the right container for the problem.

What a tab does and does not own

A browser tab is a view. By default it owns almost nothing. It borrows the cookie store, the local storage, the cache, the extension set, and the permission grants from the profile that opened it. Two tabs pointed at the same service are, to that service, the same visitor.

That is why signing in to a second account in a second tab logs out the first. The tabs were never separate. They were two windows onto one set of cookies.

Isolation, then, means giving a tab its own cookie jar: a private store of cookies, local storage, IndexedDB, and session state that no other tab can read. Everything else people associate with account separation follows from that one thing. Get the cookie jar right and two accounts coexist. Get it wrong and no amount of tab management helps.

The practical consequence is that "isolated tab" is not a setting on a tab. It is a property of the storage the tab was opened against, decided at the moment the tab is created. This is why the fix is never a tab management extension or a better grouping habit. Those operate on the view, and the view was never the problem.

One point of confusion is worth clearing up. Modern browsers have been rolling out storage partitioning, where embedded third-party content gets a separate storage bucket depending on the site it is embedded in. That is a privacy measure aimed at cross-site tracking. It does nothing for two of the same account signed in as different users, and it is not the mechanism being described here.

The three mechanisms available on macOS

Container tabs

Firefox Multi-Account Containers, published free by Mozilla, is the only widely used implementation of per-tab isolation in the literal sense. Each container has its own cookie jar. Tabs are marked with a colored underline, sites can be pinned so a domain always opens in a chosen container, and containers live together in one window.

This is exactly what "multi account browsing in isolated tabs" describes. Two Gmail accounts, two containers, one window, both signed in, neither aware of the other.

The limits are worth stating plainly. Containers isolate storage, not identity. The IP address, the browser fingerprint, and the installed extension set are shared across every container. An extension that reads page content reads it in all of them. And containers exist only in Firefox, so this approach means committing to Firefox for the accounts that need separation.

Profiles

Chrome and Safari both isolate at the profile level instead. A profile owns its cookies, history, bookmarks, extensions, and permission grants, and each profile gets its own windows. Safari added profiles in macOS Sonoma, with tab groups scoped per profile.

The isolation here is stronger than containers, because extensions are separated too. The unit is larger: a window, not a tab. Two accounts of the same service can be open at once, but never side by side in the same window.

Per-service sessions in a desktop client

The third mechanism appears in applications that wrap web services rather than browse the web. Each service is given a persistent, named session, so two instances of the same service can be signed in as different accounts with no relationship between them. This is how free open source clients such as Ferdium work, and how most commercial equivalents work. The comparison with Ferdium covers how that model differs from a browser in day to day use.

How the three compare

	Firefox containers	Chrome or Safari profiles	Per-service sessions
Isolation unit	Tab	Window	Service instance
Separate cookies	Yes	Yes	Yes
Separate extensions	No	Yes	Not applicable
Two accounts in one window	Yes	No	Yes
Cost	Free	Free	Free or paid, depending on the tool
Works outside one browser	No	No	Yes

The row that decides most cases is the last one. Containers and profiles are both features of a specific browser, which means the isolation ends where that browser ends. A link opened from a chat app, a calendar, or a terminal goes to the system default browser under the system default profile, and lands wherever it lands.

What isolated tabs still do not solve

Assume the cookie jars are correct. Two accounts, cleanly separated, both signed in. Four problems remain, and none of them are about isolation.

Finding the tab. Isolation makes both accounts available. It does not make either one findable. A window holding forty tabs, six of which are containers, is harder to navigate than one holding forty plain tabs, because the container color is the only signal and it is four pixels tall.

Routing incoming links. A shared document link arrives in Slack. macOS hands it to the default browser, which opens it in whatever container or profile was last active. If the document belongs to the other account, the result is a permission error, followed by copying the URL and opening it manually in the right place. Container pinning helps when the domain maps cleanly to one account. It cannot help when the same domain serves two accounts, which is the entire premise of multi account browsing.

Notifications. Permissions are granted per container or per profile, so the same site asks repeatedly. When a notification does arrive, it identifies the site, not the account behind it.

Restoring the layout. Containers and profiles survive a restart. The arrangement does not. Reopening the right tabs in the right containers after a reboot is manual work, every time.

These are not defects in the isolation. They are evidence that the tab is carrying a job it was not designed for. A tab was built to be cheap and disposable, opened for a minute and closed without thought. An account is the opposite: long lived, returned to daily, and expensive to reconstruct once lost. Asking one to behave like the other is the source of every remaining complaint on the list above.

Setting it up, in order

For a Firefox based setup, install Multi-Account Containers from Mozilla, create one container per account rather than per service, and pin the domains that map to exactly one account. Naming containers after the account, not the tool, avoids the case where "Work" contains three different work identities.

For a Chrome or Safari setup, create one profile per account and give each profile its own window on its own desktop space. On macOS, assigning a window to a specific desktop through the dock context menu makes switching a swipe rather than a search.

Whichever mechanism is chosen, audit the result once. Open each account's main service, check the account indicator in the corner, and confirm it matches the container or profile it is supposed to live in. A setup that looks correct because the right tabs happen to be open is not the same as a setup that is correct. The cheapest way to test it is to quit the browser entirely, reopen it, and see which account each pinned site returns to.

In both cases, the step that matters most is the least technical one: decide which account owns the default browser. Every link that arrives from outside a browser will open there, so it should be the account that receives the most links, not the one used the longest.

Four ways the isolation quietly stops working

A container setup rarely fails loudly. It degrades, and the degradation is easy to miss because nothing throws an error.

Naming by service instead of by account. A container called "Google" holds both Google accounts, which puts the setup back where it started. The name that survives is the identity: the employer, the client, the personal self. Anything belonging to that identity goes in that container, regardless of which service it is.

Signing in outside the container once. A single login to the work account in an unassigned tab writes work cookies into the default jar. Nothing breaks immediately. Weeks later the default jar holds a mixture, and the container that was supposed to be the work boundary is now one of two places work lives.

Trusting a pinned domain that serves two accounts. Pinning works because a domain maps to one container. The moment the same domain is needed by two accounts, the pin sends both to the same place, and the second account silently gets the first account's session.

Forgetting that extensions cross the boundary. In Firefox, extensions run across every container. A note taking extension, a screenshot tool, or a password manager sees all of them. For separating personal browsing from work browsing this is usually acceptable. For separating two clients under a confidentiality obligation, it is not, and profiles rather than containers are the correct unit for that case.

The pattern behind all four is the same. Isolation is a property of the storage, but the boundary is maintained by habit, and habits erode under time pressure. A setup that requires a decision at every login will eventually be wrong.

When the tab is the wrong unit

The signal is repetition. If the same three services are opened in the same three containers every morning, the tab is not being used as a tab. It is being used as an application that happens to be rendered inside a browser, and it is being rebuilt by hand each day.

At that point the useful move is to stop asking a tab to behave like an app and give each account an actual window with a persistent session, grouped by the work it belongs to rather than by which browser feature isolates it. That grouping is what Workspaces describes, and the list of services that keep their own session is on the supported apps page.

The tradeoff is real and goes both ways. Tabs are cheap, disposable, and infinitely flexible. Windows are heavier and easier to find. Anything used briefly and abandoned belongs in a tab. Anything opened every day and never closed has already stopped being one.

What to change first

Pick the one account that causes the most wrong window openings, and give it a dedicated container or profile with the domains pinned, before touching anything else. Run it for a week and count how often a link still lands in the wrong place. If the count stays high, the problem is routing rather than isolation, and that is the point at which a per-service tool such as SpaceDeck is solving a different problem than a container does.