Firefox Multi-Account Containers: what the extension separates, and what it does not

The problem Multi-Account Containers solves, and for whom

Most people who juggle two accounts on the same service end up doing one of three things: a second browser, a private window, or a second operating-system profile. Each has a cost. A second browser is a second set of extensions and bookmarks. A private window throws away the session when it closes. A second profile means two Firefox installations sharing nothing, including your settings.

The Multi-Account Containers extension takes a different route. The README describes it as carving out "a separate box for each of your online lives", and the package description in package.json says the labels and colour-coded tabs keep activities "like online shopping, travel planning, or checking work email" separate. The audience is anyone who stays inside Firefox and wants simultaneous logins without leaving it: a contractor with two client accounts, someone with a personal and a work Google login, a person who wants shopping sites to stop following them into the rest of their browsing.

It is not a privacy product in the anonymity sense. The README makes no claim about hiding your IP address or defeating tracking scripts. What it separates is cookies, per container, which is a narrower promise than it sounds.

How cookie separation by container actually works

The extension is listed in the repository as a WebExtension, built with web-ext and packaged from the src/ directory. Firefox itself provides the underlying mechanism through its contextual identities API; the extension is the interface on top of it. That distinction matters, because it explains both what the extension can do and why it will never run outside Firefox.

A container is a named identity with a colour and an icon. When a tab is opened in a container, Firefox tags the requests from that tab with the container's identity, and the browser's cookie store keys cookies by that identity rather than by site alone. Two tabs on the same domain in different containers therefore hold different cookie jars. Logging into a work account in the Work container does not disturb the personal session in another container, even though the hostname is identical.

The extension adds the layer users actually touch: a toolbar popup for creating containers, a list of sites assigned to a container, and a way to open a link directly into a chosen container. The colour coding is not decoration. It is the only signal most users have that a tab is in the container they think it is in, which is why the README leads with it.

One consequence worth stating plainly: because the separation is cookie-scoped, a site that recognises you by fingerprint, by a first-party login token stored elsewhere, or by an embedded third-party iframe can still correlate the two sessions. Containers change the cookie jar, not the browser's observable surface.

Installing Multi-Account Containers and opening a first contained tab

The README does not carry install instructions. It links to Mozilla's end-user documentation at support.mozilla.org/en-US/kb/containers, and the repository homepage points at the addons.mozilla.org listing. That listing is where a normal user installs it; the steps below follow the add-on route, and the build route is for anyone working from source.

Install from the add-ons site, then confirm the extension is present in Firefox's add-ons manager. Once installed, the toolbar button opens the container panel.

# Install from the add-ons listing:
# https://addons.mozilla.org/firefox/addon/multi-account-containers/

# Or build the extension from a checkout of the repository:
npm install
npm run build

The build script in package.json runs web-ext build against src/, which produces an artifact in web-ext-artifacts. For a live development session rather than a package, the same file defines a dev script that runs web-ext against the source tree:

npm run dev

With the extension loaded, open the container panel from the toolbar, create a container and give it a name and a colour. Then open a site inside it. The everyday pattern is to right-click a link and choose to open it in a container, or to assign a site so that future visits land in the right one automatically. The thing to watch is the tab indicator: if it does not show the container you expect, the session you are about to log into is sharing cookies with the default context.

If you are working from source rather than the add-on, note that the repository ships lint and test scripts as well, so a local checkout is expected to pass them before a patch is proposed.

Where containers stop being the right tool

The most common misunderstanding is that a container is a sandbox. It is not. It scopes cookies. If you need process isolation, a separate Firefox profile gives you a genuinely separate cookie store, separate history, separate extensions and separate saved passwords, and the search questions show people comparing the two directly. Containers are lighter and run inside one window; profiles are heavier and run as distinct instances. Choosing containers when you wanted profiles leaves you with weaker separation than you assumed.

A second limitation is platform. The extension is a Firefox WebExtension, and the related searches show a steady stream of people looking for "multi account containers chrome", "multi account containers edge" and "multi account containers brave". The repository offers no build target for any of those browsers, and the mechanism it depends on is Firefox's own. There is no port here to install.

A third is mobile. Firefox for Android is frequently searched alongside this extension, and nothing in the repository describes an Android build or an Android install path. Treat desktop Firefox as the supported surface until you have verified otherwise in the add-on listing.

Finally, the README is thin. It covers contributing, the licence and where to ask questions, and defers all user-facing behaviour to the support site. If you are evaluating the extension for a team, the repository will not tell you how rules behave when they conflict, or how container data is exported and restored. Those answers live in Mozilla's support documentation, not here.

Containers against Firefox profiles, and what to use instead

The honest alternative is Firefox's built-in profile feature. A profile is a complete separate Firefox environment: its own cookies, its own logins, its own extensions, its own history. Containers share all of that except the cookie jar, and they share it deliberately, because the point is to keep one window and one set of bookmarks while splitting identities.

The practical difference shows up in three places. First, window management: containers live in tabs, profiles live in separate windows or separate application instances, so containers scale better for quick switching and worse for keeping two contexts visually distinct. Second, scope: a profile protects you from cross-contamination in every dimension, a container protects cookies only. Third, friction: creating a container is a few clicks inside a running browser, while a new profile means launching Firefox with the profile manager and setting the new instance up from scratch.

If your reason for wanting containers is that you do not want a site to see your other session, a profile is the stronger answer, and containers are the more convenient one. If your reason is that you want two logins open at the same time in the same window, containers are the only one of the two that does it without a second window. For anyone outside Firefox, neither option is available, and the extension is not the tool to reach for.

Maintenance, licensing and the cost of upgrading a WebExtension

The repository is not archived. The most recent push recorded is 2026-09-22, and the most recent release in the list is 8.3.8 from 2026-06-17, with 8.3.5 and 8.3.4 before it in late 2025. The package.json in the repository declares version 8.4.0, which is ahead of the published release list, so the source tree and the shipped add-on are not always at the same number. Anyone tracking the project should read the release notes rather than the package version when deciding what users actually have.

Upgrade cost for users is low. Firefox add-ons update through the browser, and there is no server component, no database and no config file to migrate. The extension is client-side only, which is also why there is no self-hosted deployment story and no operational surface to maintain.

For contributors the cost is higher than the README lets on. The package.json pulls in eslint with the no-unsanitized and promise plugins, stylelint, htmllint, mocha, nyc, sinon and addons-linter, and the lint script fans out across JavaScript, CSS and HTML. A patch that touches the popup UI has to satisfy all of those before it lands, and the addons-linter gate in particular is not something you can skip locally and hope CI forgives.

The licence is MPL-2.0, a file-level copyleft. Modifications to covered files stay under the same licence when distributed, and the README points to the canonical text at mozilla.org. That is a summary, not legal advice; if you plan to ship a modified build, read the licence yourself.

Editorial conclusion

Adopt it if you already run Firefox and want work, personal and shopping sessions open side by side without a second browser or a second profile. Do not adopt it if you need Chrome or Edge, or if you expect container isolation to hide you from a site that fingerprints the browser rather than the cookie jar. Before relying on it, verify which container a tab is actually in via the tab's container indicator, and check that the sites you care about are covered by an assignment rule rather than by manual opening.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. mozilla/multi-account-containers on GitHub
3. Project website
4. README
5. Releases