Firefox multi account containers, and where they stop helping

Two Google accounts, one browser, and a sign-out loop that repeats several times a day. That is the problem Firefox containers were built for, and they solve it well. The confusion starts afterward, when containers get treated as a general fix for a cluttered working day and the clutter does not go away. Containers separate cookies. They do not separate windows, notifications, or applications. Knowing which of those is actually the bottleneck decides whether the next step is a browser setting or something else entirely.

What a container actually isolates

The feature ships as an extension from Mozilla called Firefox Multi-Account Containers. According to its listing on the official add-ons site, it has roughly 403,827 daily users, a 4.59 average rating across 8,059 reviews, and a current version of 8.3.8 last updated on 1 July 2026. The listed compatibility is Firefox 91.1 and above, desktop only.

The mechanism is narrow on purpose. Each tab carries a container label, and the cookies and site storage that tab receives are scoped to that label. A Google session created inside a container named Work is invisible to a tab labelled Personal. That is why two tabs can both sit on mail.google.com, signed in as different people, indefinitely.

What the label does not touch is everything else. History is one list. Bookmarks are shared. Saved passwords are shared. Installed extensions and their settings are shared. A container is not a second Firefox profile. It is a partition inside a single profile, and it partitions exactly one thing.

That distinction matters because the word "separate" gets used for two different layers. Chrome profiles sit at the wider layer:

With profiles, you can keep all your Chrome info separate, like bookmarks, history, passwords, and other settings. Source: support.google.com

Neither approach is better in the abstract. One partitions cookies inside a profile; the other partitions the profile itself. The gap between those two layers is where most of the disappointment with containers comes from.

Setting them up, and the one decision worth making first

Installation takes a few minutes. The extension is installed from the Mozilla add-ons site, which adds a container icon to the toolbar. Selecting that icon lists the default containers, typically Personal, Work, Banking and Shopping, each with an editable name, color and icon. Long-pressing the new tab button opens a tab in a chosen container.

The decision that shapes everything afterward is granularity. Containers can be built per account or per job. If five clients each come with their own Google account, Slack workspace and Notion, one container per client will hold up better than one container per service. Color is the only signal visible at a glance, since the container strip appears as a thin line above the tab, so colors should map to something meaningful rather than being assigned at random.

Building too many is the common failure. There is no separate tab strip per container; every tab from every container sits in the same row. Past roughly ten containers, reading the strip becomes guesswork. Three or four to start, expanded only when something concrete is missing, keeps the setup legible.

Site assignment is the second half of the setup. Opening a site inside the intended container and turning on the "always open in this container" option means that future links to that domain prompt to reopen in the right place. Assignment works at the domain level, which is exactly where Google services get awkward: personal and work identities both live under google.com, so one domain cannot be assigned two ways.

Containers do sync in a limited sense. The published release notes for version 8.3.8, released 17 June 2026, include a change making a new color syncable, and the project keeps a public release history. What travels between machines is the container definitions and assignments, not the sessions. A new Mac still means signing in again inside each container.

Containers compared with private windows and second browsers

Before containers, the standard workarounds were a private window or a second browser, and both are still in wide use. They are worth naming because they fail in specific, predictable ways that containers fix.

A private window does isolate the session, but it discards it on close. Signing back into a second work account every morning is exactly the loop the setup was meant to remove. Private windows also share one pool: opening a second private window does not create a third identity, so the trick tops out at two accounts.

Installing a second browser works and is genuinely free, but it duplicates everything. Two sets of extensions, two sets of settings, two places where a bookmark might be, and two applications competing for memory on the same Mac. It also splits the default-browser question: links opened from a mail client go to one of them, and the other one is always the wrong one.

Containers avoid both problems. Sessions persist across restarts, the number of identities is not capped at two, and there is one browser to maintain. The cost is that the isolation is invisible unless a color is being read, and that everything outside cookies stays pooled. That trade is a good one for account switching specifically, and a poor one for anything to do with focus.

There is one more comparison worth making, because it is often conflated. Firefox's tracking protection also partitions storage between sites, but it does that to stop cross-site tracking, not to let a person hold two identities. The two features operate on the same underlying storage and are easy to mix up in a settings screen, yet only containers are controllable by hand.

The three places containers stop helping

Windows and notifications stay merged. Six containers still produce one browser window and one tab strip. Slack and Gmail alerts still arrive from a single application. Switching applications with the keyboard lands on Firefox, undifferentiated. A day that starts with forty open tabs still has forty open tabs after containers are configured. The cookies were separated; the attention was not.

Anything outside Firefox is unaffected. Some business tools only support Chromium-based browsers for certain features, particularly admin consoles and video calls. When that happens, a second browser gets opened, and the account separation that was carefully built in Firefox has to be rebuilt on the other side. The tidiness is real but local.

Phones are out of scope. The add-on listing registers compatibility with desktop Firefox only. Opening the same service on an iPhone returns to a single signed-in identity, regardless of how the Mac is organized.

None of these are defects. They are the boundary of a cookie-scoping feature being asked to do window management.

Problems that show up in the first week

A few issues come up often enough to be worth anticipating, since each one looks like a broken feature and is not.

Links open in the wrong place. A link inherits the container of the tab it was clicked in. A billing link followed from a work Slack tab opens with the work identity, even when the personal account was intended. Site assignment fixes most of this by adding a prompt, but assignment is per domain, so services that host several identities on one domain still need a manual choice.

Sessions disappear overnight. If Firefox is configured to clear cookies on exit, or privacy settings are set aggressively, container contents are cleared along with everything else. Containers isolate cookies; they do not preserve them. Isolation and retention are two different settings and both need checking.

The container list vanishes when the extension is disabled. The underlying partitioning belongs to Firefox itself, while the extension provides the interface for naming, coloring and assigning. Turning the extension off removes access to that interface. Nothing is instantly destroyed, but the mapping of which sites belong to which container becomes unreachable, so writing that mapping down before moving to a new machine saves rebuilding it from memory.

Startup feels slower. When that happens, the number to check is open tabs, not containers. A container is a label on a tab and does nothing to reduce what a tab costs. Web apps left running all day accumulate, and adding labels to them can create the impression that the labels caused the weight. Deciding which apps stay open permanently, and closing the rest, changes the number. Tidying containers and tidying tab count are separate jobs with separate results.

Choosing the layer that matches the problem

Layer	Firefox containers	Browser profiles	A window per app
Cookies and sessions	Separated per tab label	Separated per profile	Separated per workspace
History, bookmarks, passwords	Shared	Separated	Depends on the tool
Number of windows	One	One per open profile	One per app or workspace
Notifications	All from one browser	All from each browser	Attached to the app that raised them
Cost	Free	Free	Usually paid
Mobile	Not supported	Supported through sign-in	Desktop focused

One row deserves emphasis. The notification column is where the three approaches diverge most and where the table is easiest to skim past. Containers and profiles both leave every alert arriving from a browser, so the mental work of deciding which account an alert belongs to is still done by the reader, several dozen times a day. Attaching an app to its own window moves that decision to the operating system, which is why people who try it rarely describe the benefit as separation. They describe it as fewer interruptions that need sorting.

Read across the table and the choice gets simpler. If the complaint is "signing in twice a day is tedious", containers are the correct and cheapest answer, and nothing further is needed. If the complaint is "the same six web apps get visited forty times a day and finding each one costs a few seconds", cookie scoping changes none of that arithmetic.

The second question is what the unit of separation should be. A per-site unit fits containers naturally. A per-job unit, where Gmail, Slack, Notion and an invoicing tool all need to switch together, is not a tab label at all. It is a working space, which is the idea behind browsers that give each app its own persistent window rather than a shared strip of tabs. The page on Workspaces describes how that grouping is meant to work in practice.

Coverage is worth checking before committing to any tool in that category, since the value depends on whether the specific services used every day are supported rather than just the obvious ones, which is what the Supported apps list is for. Products in this space differ in pricing model and in how much of the browser they replace, so a direct side-by-side such as Compared with Wavebox is a faster way to find the differences than installing three of them over a weekend.

What to change first

Install the containers extension, create three containers, and assign the two or three domains that cause the most sign-out cycles. That takes under ten minutes and costs nothing. If a week later the sign-in loop is gone but the day still feels fragmented, the bottleneck was never cookies, and the next thing to change is how many windows the work lives in rather than how many labels the tabs carry. SpaceDeck sits at that second layer.