Firefox Multi-Account Containers: One Browser, Many Isolated Sessions
Firefox Multi‑Account Containers give each tab group its own cookie jar and storage, letting you run separate work and personal sessions of the same site in one window. Here’s how the isolation works, where it breaks, and how to verify it.
11 May 2026, 02:13 UTC

If you've ever been signed into the wrong Google account and pasted a personal link into a work chat, you've hit the problem Multi-Account Containers solve. Firefox can run several fully independent sessions of the same site side by side in one window — no private windows, no separate profiles, no logging out and back in.
The useful takeaway: containers partition cookies, localStorage, IndexedDB, and cache per tab group, so a site in your Work container literally cannot see the session you have in Personal. What they don't do is hide your traffic — more on that below.
What a container actually isolates
Firefox attaches an internal identifier called userContextId to each tab. Every piece of site state written from that tab — cookies, localStorage, IndexedDB, service worker registrations, and the HTTP cache — is keyed by that ID. Two tabs with different userContextId values are, from a website's perspective, two different browsers.
This is the same partitioning machinery Firefox uses for Total Cookie Protection, which isolates third‑party cookies per first‑party site. Containers just expose the mechanism to you, keyed by your own labels instead of by site.
An interesting engineering detail: the official Multi‑Account Containers extension isn't privileged browser code. It's built on the contextualIdentities WebExtension API, the same API any extension author can use to create containers, query them, and open tabs inside them. That's a deliberate design choice — the isolation lives in the platform, the UI lives in an extension.
A worked example: work and personal in one window
The classic setup for a developer:
- Install the Multi‑Account Containers extension from Mozilla's add‑ons site (it needs permission to manage tabs and containers).
- Click the extension icon and create two containers: Work (blue) and Personal (green).
- Long‑press the new‑tab button (or use the extension menu) to open a tab in Work. Sign into your corporate Google account there.
- Open a second tab in Personal and sign into your personal Gmail.
Both sessions stay live simultaneously. The tab strip shows a colored underline and label per tab, so you can tell at a glance which identity you're acting as. You can verify the isolation yourself: open the Storage Inspector (Shift+F9, or DevTools → Storage) in each tab and confirm the cookie jars are disjoint. The Network Monitor will show each tab sending only its own container's cookies.
You can also assign sites to always open in a container — check Always open this site in… from the container menu — so clicking a calendar link lands in Work automatically.
The sharp edges
Assignment is per‑tab, not per‑window. This is the mistake everyone makes once: you open a link with Ctrl+click or from an external app and it lands in the default (no) container, silently breaking your isolation. The site now has a fresh, unauthenticated view of you — or worse, you log in there and now have state in two places. Get in the habit of checking the color bar before typing credentials.
Containers isolate storage, not the network. Your IP address, TLS fingerprint, and DNS lookups are identical across containers. Your employer's network or ISP sees the same traffic either way. Containers reduce cross‑site cookie correlation — a tracker embedded in Work can't match its cookies against the same tracker in Personal — but they are not an anonymity tool and don't replace a VPN or Tor.
Cross‑device sync of container assignments has historically been limited. Firefox Sync handles many things well, but treat container configuration as per‑device unless you've verified the behavior on your current version.
Check it before you trust it
The contextualIdentities API and default tab behavior can shift between releases, so verify on your installed version rather than trusting any write‑up (including this one):
- Confirm two containers hold separate sessions on the same site at once — Gmail is the easiest test.
- Open
about:preferences#privacyand the DevTools Storage Inspector to confirm per‑container partitioning. - Deliberately open a link in the default container and observe that it starts with no session — that's the failure mode you need to recognize in daily use.
If those three checks pass, containers will genuinely change how you handle multi‑account work. Set up Work and Personal today, pin your most‑cross‑contaminated site to its container, and you'll stop doing the logout‑login dance within the week.
0 replies
A thoughtful contribution can make all the difference. Be the first to share one.