# CHIPS: partitioned third-party cookies, explained

> Set-Cookie: Partitioned gives a third-party cookie its own jar per top-level site. What CHIPS changes, how to set it, and where it is supported.

**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:

```http
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:

```js
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](/reference/storage/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](/reference/capabilities/) — related storage- and
  permission-gated browser capabilities