A partitioned cookie, set with the Partitioned attribute under CHIPS, is stored separately for each top-level site that embeds your content. Your widget can keep its state on one site without being able to read that cookie when embedded on another, which blocks cross-site tracking.
The problem CHIPS addresses
Historically, if a page embedded a third-party iframe, that third party could set a cookie and read it again when embedded on any other site. MDN says this enables tracking of user activity across unrelated sites. CHIPS (Cookies Having Independent Partitioned State) lets a developer opt a cookie into partitioned storage, with a separate cookie jar per top-level site.
Partitioned cookies are double keyed: by the host that set them and by the site of the top-level page.
The syntax
Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;
MDN states that partitioned cookies must be set with Secure. It recommends the __Host prefix as well, to bind them to the current host rather than the registrable domain, unless you need to share between subdomains.
A worked example
Take a chat widget at a third-party host, embedded on two retail sites.
- A visitor opens the first site, and the widget sets a partitioned cookie. The storage key now includes that first site.
- The visitor opens the second site, which embeds the same widget. The widget cannot read the first cookie, because the partition key differs.
- Within the first site, the widget embedded on its subdomains, such as support and checkout, can still read the cookie, since the partition key is based on the site.
When to use it, and when not
| Situation | Partitioned cookie fits? |
|---|---|
| Embedded chat or support widget that keeps conversation state per site | Yes |
| Embedded map that remembers preferences per embedding site | Yes |
| CDN load balancing config per site | Yes, per MDN |
| Single sign on that must recognise a user across different sites | No, the cookie is invisible across top-level sites |
| Cross-site advertising identity | No, that is what partitioning prevents |
MDN lists legitimate uses as persisting state of embedded maps or chat widgets across a domain and its subdomains, and config for subresource CDN load balancing and headless CMS providers.
Developer checklist
- Identify cookies your embedded service sets in a third-party context.
- Add
Partitioned, keepSecure, and useSameSite=Nonesince the cookie is sent in a cross-site context. - Prefer a
__Host-name unless subdomain sharing is needed. - Test the embed on two different top-level sites to confirm state does not leak across.
- Test in a browser that partitions by default, since MDN notes Firefox's state partitioning differs: it partitions by default, while CHIPS is an opt in. Use the opt in so behaviour is consistent.
Partitioning is a privacy feature, not an authentication control. A partitioned session cookie should still be HttpOnly where scripts do not need it, and short lived.
For the first party side of cookie hardening, see secure cookie flags explained.
Quick check
Does Partitioned require Secure?
Yes. MDN says partitioned cookies must be set with Secure.
Can the same widget read its cookie on a different site?
No. The partition key is based on the top-level site, so a different site gets a different cookie jar.
Safeguard helps teams keep embedded and third-party components visible through SBOM and dependency scanning. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
