Firefox Total Cookie Protection: How State Partitioning Works and What It Breaks

Blocking third-party cookies sounds simple until a login widget, an embedded video, or a payment frame stops working. Firefox took a different route from blocklists: instead of refusing cross-site storage, it gives each top-level site its own copy. Mozilla markets this as Total Cookie Protection, and the engineering name is state partitioning. It is on by default for all Firefox users, and it explains both why trackers lose their cross-site memory and why some embeds behave oddly.

The Mechanism: Double-Keyed Storage

Under the older model, a tracker embedded on two sites read and wrote the same cookie jar for its own origin on both. That shared jar is what let it recognize you across them. Partitioning removes the sharing. According to Mozilla’s documentation, Firefox double-keys client-side state by two things: the origin of the resource being loaded, and the top-level site the user is visiting, typically the scheme plus registrable domain.

The result is that an embedded tracker.example gets a separate bucket under each site that embeds it. An ID written while it is embedded on one site cannot be read back when it is embedded on another, and it cannot be read from a direct visit to tracker.example either. The tracker still functions inside each site. It just cannot connect the dots between them.

What Gets Partitioned

Mozilla’s State Partitioning page groups the affected state into three kinds.

• Storage APIs, partitioned statically: localStorage, sessionStorage, the DOM Cache, IndexedDB, Broadcast Channel, Shared Workers, and Service Workers.
• Cookies, partitioned dynamically: document.cookie is the only API in the dynamic category, which matters because dynamic partitioning is the kind sites can ask to lift.
• Network state, partitioned permanently: HTTP, image, script, stylesheet, font and favicon caches, connection pooling, DNS, HSTS, TLS session identifiers, HTTP authentication, and more. Sites cannot relax this layer.

The timeline is staggered. Network partitioning reached all users in Firefox 85. Dynamic partitioning went to Strict-mode users in Firefox 86, private browsing in Firefox 90, and to everyone by default in Firefox 103.

The network layer is the part most guides skip. Cache partitioning is a quiet cost: a font or library loaded from a shared CDN is no longer reused across sites, because a shared cache would itself be a tracking signal.

What It Breaks

Anything that assumed one shared jar per origin across sites is affected. The most common patterns are:

• A third-party widget that expects a session created on its own site, such as a comment system or support chat that recognizes you from visiting its domain directly.
• Embedded content, like video players or payment frames, that relies on state set during an earlier first-party visit.
• Single sign-on flows implemented through cross-site cookies instead of redirects.
• Cache-dependent performance assumptions, since cross-site cache hits no longer happen.

Mozilla’s own page has no dedicated breakage section, so the list above is inferred from how the mechanism works, not quoted from a defect catalog. The failures are real but contextual, which is why they surface as user reports rather than a single API error.

How Sites Get Access Back

Firefox gives sites two routes to unpartitioned storage.

The Storage Access API. A third-party frame can call document.requestStorageAccess(). If the browser grants it, the frame gets its normal first-party cookies, as if the user had visited it directly. Mozilla’s documentation shows the call wrapped in a try/catch with a fallback to partitioned storage, which is the pattern to follow, because the request can be denied.

Heuristics. To limit breakage, Firefox automatically grants access in some situations. In the opener heuristic, a partitioned third party opens a popup with window.opener access and the user interacts with it; the third party then gets storage access to its embedder for 30 days. A navigation heuristic works similarly for a quick round trip between two sites, also for 30 days. Automatic grants also apply to federated login providers. Users can revoke a grant in the Site Information panel under Cross-site Cookies.

Mozilla is explicit that the heuristics are transitional and should not be relied on for current or future development. Build to the Storage Access API.

Debugging a Suspected Partitioning Bug

Firefox’s developer console reports why a frame’s storage behaved as it did, distinguishing partitioned, heuristic-granted, and API-granted states. For testing, Mozilla documents preferences such as privacy.antitracking.enableWebcompat, which when set to false disables the compatibility features so you can see strict partitioning. Use a separate Firefox profile for that, since the preference changes browser behavior broadly.

What It Does Not Do

Partitioning does not stop first-party tracking. A site you visit directly can still set cookies and recognize you, which is why cookie banners still matter; our cookie consent managers article covers that side. It also does not by itself stop fingerprinting or bounce-style redirect tracking. For the wider history of how browsers moved on cross-site cookies, see the third-party cookie phase-out and Chrome’s SameSite default.

The Takeaway

If you build embeds or widgets, test in Firefox with the compatibility features off, replace any reliance on heuristics with an explicit requestStorageAccess() call, and keep a working fallback. If you are a user hitting a broken login inside a frame, the Site Information panel shows whether a grant exists, and opening the embedded service in a popup or tab and interacting with it can, in some flows, trigger the heuristic grants described above.