Firefox Multi-Account Containers: Isolating Your Online Identity

Firefox Multi-Account Containers is a first-party Mozilla extension that gives each container its own segregated cookie jar, localStorage, IndexedDB, and cache. Tabs in different containers cannot read each other’s state. The same tracker code embedded on two different sites will write cookies that are invisible across containers — the tracker on your shopping site cannot see the cookie it set on the news site if they’re in different containers.

This is different from private browsing mode. Private browsing destroys state when the window closes. Containers persist state within each container indefinitely while keeping containers isolated from each other. The right mental model is separate browser profiles within a single Firefox window.

Installation and Setup

Multi-Account Containers is available at addons.mozilla.org/en-US/firefox/addon/multi-account-containers/. It’s a first-party Mozilla extension — maintained by Mozilla, not a third party.

After installation, four default containers are created: Personal, Work, Banking, Shopping. These are starting points; rename, delete, or add containers freely. Each gets a distinct color and optional icon that appears in the browser tab to identify the container context.

To open a link in a specific container: right-click → “Open Link in New Container Tab.” The extension also lets you set default containers per domain — Site A always opens in Work, Site B always opens in Personal. This automatic assignment is the feature that makes containers practical at scale.

The Privacy Model: What Containers Actually Isolate

Containers partition:

  • Cookies — each container has its own cookie jar. First-party and third-party cookies are kept separate per container.
  • LocalStorage and SessionStorage — the same key on example.com in the Work container contains different data than in the Personal container.
  • IndexedDB — same isolation.
  • Cache — separate HTTP cache per container, preventing cache-timing attacks and cache-based tracking across containers.
  • Service workers — service workers run in the context of the container that registered them.

Containers do not isolate:

  • IP address — all containers share your real IP unless you’re using a VPN or Tor.
  • Browser fingerprint — canvas, WebGL, font enumeration, screen dimensions are the same across all containers.
  • Browsing history — history is unified across containers (though container context is noted).
  • Downloaded files — files are saved to disk regardless of container context.

The isolation model is effective against cross-site tracking via cookies and storage. It is not effective against IP-based tracking, fingerprinting, or any technique that doesn’t rely on shared cookies.

Practical Container Architecture

Here’s a configuration that covers most people:

Personal — General browsing, news, entertainment. Sites that don’t need login separation from everything else.

Work — Google Workspace, company tools, work email, work Slack. Work cookies stay here; work authentication doesn’t bleed into personal browsing.

Banking — Financial institutions only. Never opened for anything else. This container never has tracking cookies from shopping or social sites.

Shopping — Amazon, retail. Shopping behavior is isolated from your reading and social behavior.

Social — Facebook, Instagram, Twitter/X, LinkedIn. These platforms are among the most aggressive cross-site trackers on the web. Containing them means their third-party pixels on other sites don’t connect to your authenticated session.

Google — If you use Google services (Search, YouTube, Maps) while signed in, a dedicated Google container prevents Google’s first-party tracking from seeing your activity in other containers.

The Facebook Container extension (addons.mozilla.org/en-US/firefox/addon/facebook-container/) automatically places all Facebook and Instagram tabs in a dedicated container and rewrites incoming Facebook-to-link clicks to redirect through the container. Install this even if you don’t actively use Facebook — Facebook’s tracking pixels are on a large fraction of commercial websites, and keeping any authenticated Facebook session isolated limits what they can correlate.

Firefox’s Total Cookie Protection (enabled in Strict ETP mode) partitions cookies by top-level site. This is different from containers: it means a tracker embedded on news.com cannot read the cookie it set when you were on shopping.com, even without containers.

Containers and Total Cookie Protection work together and are complementary. Total Cookie Protection handles the tracker case. Containers handle the case where you want the same first-party site (say, google.com) to behave differently depending on whether you’re in your Work container or your Personal container. They partition the state along different axes.

Running both is straightforward — Total Cookie Protection is automatic in Strict ETP, and containers layer on top.

Site Assignment: Making It Automatic

The most useful feature after initial setup: right-click the Multi-Account Containers icon when you’re on a site → “Always Open This Site in [Container].” After assigning a domain, every time you navigate to that domain Firefox automatically reopens it in the assigned container.

Workflow implications:

  • Set up site assignments for every site where logged-in state matters.
  • Sites that don’t have assignments open in whatever container you’re currently in, or in the default (no container) context.
  • The extension handles subdomains correctly — assigning google.com affects mail.google.com, drive.google.com, and others.

Containers and Firefox Sync

Container assignments and container configurations sync across devices if you use Firefox Sync. The container isolation itself is local — each Firefox installation maintains its own isolated storage. Sync transfers the rules for which sites open in which containers, so your setup works on all your Firefox installations without manual reconfiguration.

Limitations and Edge Cases

Third-party embeds. If you’re in the Personal container and a page embeds a widget from widget.com, that widget runs in the Personal container’s context. If you later visit widget.com directly in the Work container, the two instances are isolated — but the embed still runs in whatever container the embedding page is in.

OAuth flows. Some single-sign-on implementations redirect through a third-party domain and back. If that third-party domain is assigned to a different container, the redirect may fail or reopen in an unexpected container. Work around this by temporarily opening the authentication flow in the same container as the destination site.

Service workers and offline apps. A site that registers a service worker in the Work container will have a different service worker registration than the same site in the Personal container. This is usually fine but can cause confusion with progressive web apps that rely on service workers for offline functionality.

Tab count. Power users with many containers and domain assignments can end up with a lot of tabs organized by container. The Container Tabs Sidebar extension adds a sidebar organized by container if the standard toolbar becomes unwieldy.

FAQ

Do containers protect me from fingerprinting? No. Fingerprinting techniques that read canvas, WebGL, font lists, or screen dimensions get the same values regardless of container. Containers isolate cookie-and-storage-based tracking, not fingerprint-based tracking.

Can I have the same site open in two containers simultaneously? Yes. Open mail.google.com in the Work container and mail.google.com in the Personal container in separate tabs. Each tab has independent cookie state. This is one of the most useful features — separate Google accounts open side by side without any credential interference.

Do containers work in Private Browsing windows? No. Private Browsing and containers are separate systems. A Private Browsing window doesn’t use containers. Some users run containers in regular windows and use Private Browsing for unrelated ephemeral sessions.

Is there a Chromium equivalent? Chrome profiles are the closest analog — each profile has separate cookie jars and storage. But Chrome profiles require separate windows, you can’t mix profiles in a tab bar, and they’re heavier-weight than containers. There’s no direct equivalent to Firefox Containers’ per-tab, per-domain isolation model in Chrome or Edge.