A Partitioned cookie is a cookie that a browser stores separately for each top-level site it is used on, rather than in one shared jar. The mechanism is called CHIPS — Cookies Having Independent Partitioned State. It exists so that a genuine third-party embed (a chat widget, a payment frame, an embedded map) can keep its own state as browsers phase out ordinary third-party cookies. You opt in by adding the Partitioned attribute to a Set-Cookie header. Most sites do not need it — it is only for cross-site embedded contexts.
What Partitioned cookies (CHIPS) are
For most of the web's history, a cookie set by widget.example was stored in a single place and sent back whenever the browser talked to widget.example — no matter which site the user was visiting at the time. That is what made tracking cookies work: one identifier followed you across every site that embedded the same third party. Browsers are steadily removing that ability.
CHIPS is the replacement for the legitimate half of that behaviour. When a cookie is marked Partitioned, the browser keys it not just by the domain that set it but also by the top-level site the user is on. So the same embedded widget on shop-a.example and shop-b.example gets two completely independent cookies. State works within each site, but nothing carries between them — the cross-site tracking channel is closed while the useful per-site state survives.
You can read the primary references at MDN: the Set-Cookie Partitioned attribute and the CHIPS explainer.
When you need Partitioned — and when you don't
The honest answer for most sites is: you don't need it. If your cookies are first-party — set by the same site the user is visiting, for your own sessions, logins and preferences — they already work and will keep working. Partitioned changes nothing useful for them and is not a security flag you should sprinkle onto every cookie.
You need Partitioned only when all of the following are true:
- Your cookie is used in a genuine third-party (cross-site) context — for example, your service is loaded inside an
<iframe>or via a script on websites you don't own. - That embedded context genuinely needs to remember state per host site (a session for a support chat, a cart token for an embedded checkout, a CSRF token for a payment frame).
- You want it to keep working after unpartitioned third-party cookies are gone, without reaching for tracking-style workarounds.
If you are a normal first-party site — a blog, a shop on its own domain, a SaaS dashboard your users log into directly — none of that applies, and adding Partitioned to your session cookie does nothing except require you to also set Secure.
How to set a Partitioned cookie
For the site owner (plain English)
If you run a normal website on its own domain, there is nothing here you have to do — this is a developer-level attribute for services that get embedded inside other people's pages. If you're not sure whether your cookies are first-party or embedded cross-site, the simplest thing is to look at what's actually being set on your pages. The cookie checker lists every cookie your site issues and its flags, so you can see at a glance whether you have any cross-site cookies that would even be candidates for partitioning.
For developers
The requirement is specific: Partitioned only takes effect on a cookie that is also Secure and, in practice, SameSite=None (because you are deliberately allowing cross-site sending). The exact header looks like this:
Set-Cookie: name=value; Secure; SameSite=None; Partitioned; Path=/Framework support varies, so check your server or library version before relying on it. A few common cases:
// Express (Node) — the "partitioned" cookie option
res.cookie("sid", token, {
secure: true,
sameSite: "none",
partitioned: true,
path: "/",
});
// Raw header, if your framework has no dedicated option yet
Set-Cookie: sid=<token>; Secure; SameSite=None; Partitioned; Path=/Not every server, framework or cookie library exposes a first-class partitioned option yet — several only gained it recently, and some still require you to append the raw Partitioned attribute to the header yourself. Confirm behaviour with your actual stack rather than assuming the option exists.
Partitioned without Secure is simply rejected — the browser ignores the attribute, so you get an ordinary (unpartitioned) cookie and none of the isolation you expected. Just as important: Partitioned is not a security hardening flag to add to every cookie. Adding it to a first-party session cookie doesn't make it safer; it only matters for cross-site embedded state.Browser support reality
CHIPS shipped first in Chrome and is available in Chromium-based browsers; other engines are at varying stages of support and the picture is still evolving. Because of that, treat Partitioned as an enhancement rather than a guarantee: a browser that doesn't understand the attribute will fall back to its normal third-party-cookie behaviour (which, in more and more browsers, means the cookie is blocked in cross-site contexts anyway). Don't hard-code assumptions about specific version numbers — check the current MDN compatibility data when you deploy, since support moves quickly.
The practical takeaway: if you own an embedded third-party service, partition its cookies now so they keep working as unpartitioned third-party cookies go away. If you run a first-party site, there is nothing to change.
See every cookie your site sets and its flags — free and passive.
Run the cookie checker →For the wider context, read the cookie security guide, and pair this with the SameSite attribute (Partitioned is used with SameSite=None) and the Secure flag that Partitioned always requires.