# Partitioned Cookies (CHIPS): The Partitioned Attribute

> The Partitioned cookie attribute (CHIPS) gives third-party embeds a separate cookie jar per top-level site. Syntax, Secure requirement, and browser support.

Source: https://howhttpworks.com/cookies/partitioned
Last reviewed: 2026-10-04

> **TL;DR:** `Partitioned` makes a third-party cookie live in a separate jar for each top-level site that embeds it. Set it with `Secure` (and `SameSite=None` if the cookie must be sent cross-site) and the cookie works inside an iframe even where unpartitioned third-party cookies are blocked, without being usable for cross-site tracking.

## What it looks like

```http
Set-Cookie: __Host-widget=34d8g; Secure; Path=/; SameSite=None; Partitioned
```

This is the form shown in MDN. A chat widget served from `chat.vendor.example` sets that cookie while embedded on `https://site-a.example`. The browser stores it under a double key: the cookie's own host (`chat.vendor.example`) and the partition key, the top-level site (`https://site-a.example`). When the same widget is embedded on `https://site-b.example`, the browser looks in a different partition and the cookie is not there. Each embedding site gets its own widget state.

CHIPS stands for Cookies Having Independent Partitioned State. It is the opt-in alternative to the older all-or-nothing model, where a third-party cookie was either sent everywhere or blocked everywhere.

## Rules

- `Partitioned` requires `Secure`. A cookie with `Partitioned` but no `Secure` is rejected.
- To be sent in cross-site requests at all, the cookie still needs `SameSite=None`; partitioning does not replace SameSite. See [SameSite](https://howhttpworks.com/cookies/same-site).
- MDN recommends the `__Host-` prefix, which binds the cookie to the exact host. See [cookie prefixes](https://howhttpworks.com/cookies/cookie-prefixes).
- The partition key is the top-level site, not the full origin. Subdomains of the embedding site share a partition: a widget embedded on `shoppy.example` and `support.shoppy.example` reads the same cookie.
- The `Cookie` request header does not say whether a cookie is partitioned. Your server only sees `name=value`, so partitioning is invisible server-side apart from the cookie being absent when the context changes.

## What it is for, and what it breaks

Intended uses from MDN: embedded maps or chat widgets that keep state per embedding site, CDN load-balancing hints, and headless CMS or embedded-service configuration. In each case the third party needs memory per site, not a cross-site identity.

It does not give you a cross-site login. A partitioned session cookie set while your app is embedded on `site-a.example` is invisible when the user visits your app directly or embedded on `site-b.example`. Federated sign-in needs another mechanism such as FedCM, or the Storage Access API for unpartitioned access.

## Browser support

Per MDN's compatibility data for the `Partitioned` attribute:

| Browser | First version |
| --- | --- |
| Chrome, Edge | 114 |
| Firefox | 141 |
| Safari | 26.2 (18.4 and 18.5 listed as partial) |

MDN labels the feature Baseline 2025, newly available since December 2025. Safari and Firefox already restrict or partition third-party cookies by default, so there the attribute mostly matters as an explicit declaration of intent; in Chrome, where unpartitioned third-party cookies can still be allowed by user settings, it is what keeps working when they are blocked.

## Chrome's third-party cookie plans

This area changed several times, so only the confirmed announcements are listed:

- 22 April 2025: Google said it would maintain its current approach to offering users third-party cookie choice in Chrome and would not roll out a new standalone prompt for third-party cookies. Users keep the choice in Chrome's Privacy and Security settings.
- 17 October 2025: Google announced it was retiring ten Privacy Sandbox technologies, including Topics, Protected Audience and Attribution Reporting, because of low adoption. CHIPS and FedCM were named as having seen broad adoption and will continue, and Private State Tokens are kept.

Neither announcement is a date for removing third-party cookies from Chrome. Build for the case where they are blocked, since Safari and Firefox already do, and use `Partitioned` where per-site state is all you need.

## Debugging

In Chrome DevTools, Application, Cookies shows the partition key for each cookie. A cookie that is "missing" in an embed is usually one of: set without `Secure`, set from an HTTP response, set without `SameSite=None` and therefore not sent, or looked up from a different top-level site than the one that set it. Test in a fresh profile, since extensions and old unpartitioned cookies can mask the problem.

```bash
curl -si https://chat.vendor.example/init | grep -i set-cookie
```

Confirm the header contains `Partitioned` and `Secure` before blaming the browser.
