Container tabs isolate cookies and site storage, not your device. Here's what gets isolated, what stays identical, and what still tracks you across containers.
Firefox is folding container tabs into the browser itself — a feature that used to require the Multi-Account Containers add-on is becoming a first-party option. That's a good moment to be precise about what a container actually does, because the mental model most people carry is wrong in a way that matters: a container is a separate cookie jar, not a separate browser. Everything below hangs off that one distinction — a reader who assumes otherwise will trust containers for something they were never built to provide.
Key Takeaways
- A container is a separate cookie jar, not a separate browser instance — MDN's
contextualIdentitiesreference states it plainly: "each identity gets a cookie store that is not shared with other tabs." In Firefox that separation carries through to the rest of a site's storage as well. - Everything below the storage layer is shared: your IP address, TLS/HTTP/2 handshake, canvas/WebGL/audio output, installed fonts, screen metrics, and timezone are identical across every container on the same browser.
- A fingerprint-based tracker sees one visitor, not two — two containers that look like separate identities to a cookie-reading site can collapse right back into a single profile the moment a site fingerprints instead of relying on storage.
- Containers genuinely stop cookie-linked cross-site identity: login-state probes and redirect-based tracking that depend on a shared cookie jar don't survive being split into isolated jars.
- They sit in a family of isolation models — private windows, separate browser profiles, and VPNs each isolate a different layer, and confusing which layer a tool covers is the most common way people over-trust their setup.
What a Container Actually Partitions
Firefox's contextual identities feature — the mechanism behind Multi-Account Containers, and now behind native containers — assigns each tab a container identity and keys site storage to that identity. MDN's contextualIdentities API reference is precise about the storage half: "Internally, each identity gets a cookie store that is not shared with other tabs," addressed by a cookieStoreId. In Firefox the container id rides along in the origin attributes attached to storage requests, so the split isn't limited to cookies in practice — localStorage, IndexedDB, and the rest of a site's storage land in different buckets per container too.
Open the same site in a "Work" container and a "Personal" container and the site sees two entirely separate storage buckets — no cookie set in one leaks into the other, and a login session started in one container doesn't carry over to the other.
Worth keeping distinct from all of this: Firefox also partitions state along a completely different axis. MDN's State Partitioning guide describes how the browser "double-keys all client-side state by the origin of the resource being loaded and by the top-level site" — covering storage APIs (localStorage, sessionStorage, IndexedDB, Service Workers) and network state (HTTP cache, image cache, DNS, TLS session identifiers, HSTS). That guide is about cross-site isolation, keyed by the site in the address bar; it says nothing about containers. You get both mechanisms at once in Firefox, and neither substitutes for the other — one stops a tracker following you between sites, the other stops your own identities seeing each other.
Either way, both mechanisms stop at the storage layer. They are real, useful boundaries — and they are the entire boundary. Neither touches what the browser reveals about the device or the network it's running on.
What Stays Identical Across Every Container
This is the part the Firefox announcement doesn't dwell on, and the part a reader is most likely to fill in with an assumption that isn't true. Container partitioning operates entirely at the storage layer. Every signal that comes from how your browser and connection behave, rather than what a site stored, is untouched:
- Your IP address and network path — a container doesn't route traffic differently or change what a server sees your connection arrive from.
- TLS and HTTP/2 handshake characteristics — the same negotiation order and parameters go out regardless of which container initiated the request.
- Canvas, WebGL, and audio output — the same GPU renders the same pixels and the same audio context produces the same waveform in every container, because it's the same hardware and driver stack underneath.
- Installed fonts and screen geometry — read live from the OS and display, not from anything a container could scope.
- Timezone and locale — reported straight from OS configuration, identical in every tab.
Combine those and you get a browser fingerprint — and a fingerprint doesn't care which container issued the request. If a site identifies visitors by fingerprint rather than by reading cookies, two containers on the same machine produce the same fingerprint and collapse into one tracked identity, no matter how carefully you kept their cookie jars apart. Our piece on fingerprint entropy and anonymity sets covers how few of these signals it actually takes to make a device uniquely identifiable even with zero cookies involved. Want to see this directly rather than take it on faith? Open the same page in two different containers and run BrowserInsight's fingerprint check in each — the resulting hash will match. If it doesn't, what changed it was an anti-fingerprinting mode adding per-site noise to signals like canvas, not the container boundary.
Containers vs. the Other Isolation Models
Containers are one entry in a small family of browser isolation tools, and they each isolate a genuinely different layer. Mixing them up is where most of the over-trust happens.
| Isolation model | What's separated | What stays shared |
|---|---|---|
| Container tabs | Cookies and site-scoped storage, per contextual identity | Device/network fingerprint, IP address — everything in the section above |
| Private/incognito window | One ephemeral storage jar, cleared on close | Device/network fingerprint; the window itself is often detectable as private via separate storage-quota behavior |
| Separate browser profile | Cookies, storage, extensions, and browser-level settings | Still the same IP address and the same underlying hardware fingerprint |
| VPN or proxy | Your network path and the IP a server observes | Every browser-side signal — cookies, fingerprint, everything above the network layer |
Read across that table and the pattern is clear: no single tool covers more than one row. A container plus a VPN addresses two genuinely different layers at once, which is closer to what people imagine "container tabs" alone provide.
Where Containers Genuinely Do Work
None of this makes containers useless — it defines exactly where their real value sits. Containers are effective specifically against tracking that depends on a shared cookie jar, and there's a meaningful category of tracking that fits that description.
Cross-site login detection — where a site infers which other services you're logged into by probing timing, error events, or redirect behavior tied to your existing session cookies — loses its signal the moment those sessions live in separate containers. If you're not logged into a service inside a given container, there's no shared cookie state left to probe.
Bounce tracking fails for the same structural reason. It briefly makes a tracker's own domain first-party during a redirect, specifically to plant or read a cookie-based identifier — and that identifier is exactly the kind of per-container storage a contextual identity keeps apart, so it can't link a visit in one container to a visit in another. In both cases, splitting your identities into separate cookie jars removes the exact mechanism the tracking depends on.
What Still Leaks Around a Container Boundary
Cookie-based tracking isn't the only kind of storage a site can lean on, and not everything that persists state is scoped the same way cookies are. ETag and cache-based supercookies hide an identifier inside ordinary HTTP cache revalidation headers rather than in cookie storage.
Here the two mechanisms above pull in different directions. The HTTP cache is on State Partitioning's list of network state that Firefox permanently keys by top-level site, which closes the cross-site version of that trick regardless of containers. What neither MDN page states is anything about the cross-container version — how a given browser and version scopes its HTTP cache per contextual identity is simply not a documented guarantee the way cookie separation is. The safe assumption: a container boundary is proven for cookies and the storage MDN describes, and unproven for anything else until you've verified it on the browser you actually use.
Containers Are a Compartmentalization Tool, Not an Anonymity Tool
The honest summary is the one the Firefox announcement leaves implicit: containers keep your identities apart from each other on the same device — a work login that never sees a personal login's cookies, a shopping session that doesn't carry ad-retargeting state into an unrelated tab. That's compartmentalization, and it's genuinely useful for exactly that purpose.
It is not an anonymity tool for hiding from a site that's watching. A site that reads cookies sees separate visitors across your containers; a site that fingerprints sees one. If you're evaluating whether to trust a browser add-on with that job in the first place, our browser extension privacy piece covers the broader question of what a piece of installed software can see regardless of which built-in isolation feature it sits next to. Keep the two goals separate in your head, and containers do exactly what they promise — no more, no less.
Frequently Asked Questions
Do container tabs hide my fingerprint?
No. Container tabs partition cookies and site-scoped storage per contextual identity; they do nothing to your IP address, TLS handshake, canvas/WebGL output, fonts, screen metrics, or timezone. All of those are identical across every container on the same browser, which is exactly what a fingerprint is built from.
Can a website tell I'm using containers?
There's no page-facing API that announces it: contextualIdentities is a WebExtensions API available to add-ons, not to the sites you visit. What a site does see is the consequence — an empty cookie jar — and that looks the same as a visitor who cleared their cookies. The catch is that "empty storage, familiar fingerprint" is itself a pattern, which is why containers are designed to keep containers unlinkable to each other through storage, not to hide that the feature exists.
Does Firefox making containers a native feature change what they isolate?
No. Native containers in Firefox 153 fold Multi-Account Containers' functionality into the browser itself, but the underlying mechanism — the same contextual-identity storage partitioning contextualIdentities has always described — is unchanged. The isolation boundary is the same one this article describes either way.
Are containers the same as private/incognito windows?
No. A private window uses one ephemeral storage jar that's cleared when the window closes; containers give you multiple persistent storage jars running side by side, each kept separate from the others. Private windows also have their own detectability quirks — see how sites detect incognito mode — that don't apply to containers at all.
Do I need a VPN if I already use containers?
They solve different problems. Containers separate your identities from each other on the same device by isolating storage; a VPN changes what network path and IP address a server sees, which containers don't touch at all. Neither substitutes for the other — see BrowserInsight's VPN and proxy check for the network-side half containers can't cover.
Recommended Reading
- Fingerprint Consistency: Why Mismatched Signals Get You Flagged
- Browser Fingerprint Entropy and Anonymity Sets Explained
- How Websites Detect Incognito and Private Browsing Mode
- Login Detection: How Sites Know Which Services You Use
- Bounce Tracking Explained: Redirects That Track Without Cookies
- ETag and Cache Supercookies: Tracking Beyond Cookies
- Browser Extension Privacy Risks: Your Add-ons May Be Watching You
