CHIPS: partitioned third-party cookies, explained

In one line: per MDN, “Cookies Having Independent Partitioned State (CHIPS, also known as Partitioned cookies) allows developers to opt a cookie into partitioned storage, with a separate cookie jar per top-level site.”

Why partition cookies at all

MDN explains the problem CHIPS addresses: “cookies marked Partitioned are double-keyed: by the origin that sets them and the origin of the top-level page. This means they can only be read within the context of the top-level site they were set on.” Without that, “third-party cookies can enable services to track users and associate their information across unrelated top-level sites” — while double-keying still lets legitimate cases work, such as “persisting state of embedded maps or chat widgets across a domain and its subdomains.”

Syntax

Per MDN, a site opts a cookie in by adding the Partitioned attribute to the Set-Cookie response header:

Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;

MDN notes that “partitioned cookies must be set with Secure,” and recommends the __Host- prefix “if you don’t need to share cookies between subdomains.”

With Partitioned set, MDN describes the resulting storage key as a pair: “the host key and a new partition key,” where the partition key “is based on the site, including the scheme, of the top-level URL the browser was visiting when the request was made to the URL endpoint that set the cookie.” A cookie set by 3rd-party.example while embedded on site-a.example is keyed as {("https://site-a.example"), ("3rd-party.example")}, so the same third party embedded later on site-b.example gets a different partition and cannot read it back.

Reading partitioned cookies from JavaScript

The CookieStore API’s getAll() method exposes each cookie’s partition status directly, per MDN’s CookieStore.getAll() reference, which documents a partitioned result field: “A boolean indicating whether the cookie is a partitioned cookie (true) or not (false).” That gives a real feature-detection path for code that wants to branch on CookieStore support before relying on it:

async function readPartitionedCookies() {
  if (!('cookieStore' in window)) {
    // No CookieStore API — document.cookie's getter only returns
    // semicolon-separated name=value pairs, per MDN, with no attributes such
    // as Partitioned, so parsing it cannot recover partition status either.
    return null;
  }
  const cookies = await window.cookieStore.getAll();
  return cookies.filter((cookie) => cookie.partitioned);
}

How this relates to Firefox’s State Partitioning

MDN’s State Partitioning article describes a broader, Firefox-specific mechanism with a similar goal but a different default: “State Partitioning is a broad effort by Mozilla to rework how Firefox manages client-side state… to mitigate the ability of websites to abuse state for cross-site tracking.” Unlike CHIPS’s opt-in model, MDN states Firefox “double-keys all client-side state by the origin of the resource being loaded and by the top-level site” by default for storage APIs including localStorage, sessionStorage, IndexedDB, and Service Workers, plus a separate, non-configurable partitioning of network caches (HTTP cache, DNS, connection pooling, and more) that MDN says “is permanent” and that “websites can’t control or relax.”

MDN’s CHIPS page draws the contrast directly: “CHIPS is similar to the state partitioning mechanism implemented by Firefox. However, state partitioning partitions cookie storage by default for third-party contexts, whereas CHIPS allows opt-in to partitioned cookies for both first-party and third-party contexts. It is recommended to use the opt-in mechanism of CHIPS rather than state partitioning to provide the most compatible partitioned cookies.”

Browser support

MDN’s compatibility data for the Set-Cookie Partitioned attribute shows support landing at different times per engine: Chrome from version 114, Firefox from version 141, and Safari from version 26.2. Check MDN’s live compatibility table before relying on Partitioned in production, since support is recent in all three engines.

Practical checklist

• Always pair Partitioned with Secure — MDN states this is required, not optional, for the attribute to take effect.
• Don’t assume a partitioned cookie set while embedded on one top-level site is readable when the same content is embedded elsewhere — per MDN’s storage-key description, a different top-level site produces a different partition key.
• Don’t rely on document.cookie to tell you whether a cookie is partitioned — per MDN’s Document.cookie reference its getter returns only a semicolon-separated list of name=value pairs, with no per-cookie attributes, so the Partitioned state a cookie carries never appears there; the CookieStore API’s getAll() partitioned field is what actually surfaces it to script.
• If you’re targeting Firefox users specifically, remember MDN’s guidance to prefer CHIPS’s explicit opt-in over relying on State Partitioning’s default third-party behavior, since CHIPS behaves consistently as a standardized mechanism across first- and third-party contexts.

Cross-references

• Storage Access API — the API third-party frames use to request unpartitioned cookie access when they need to escape partitioning rather than opt into it
• Web capabilities index — related storage- and permission-gated browser capabilities