< Set-Cookie: __Host-id=a3fWa; Secure; Path=/; SameSite=None; Partitioned

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

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.
• MDN recommends the __Host- prefix, which binds the cookie to the exact host. See 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.

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

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