How CHIPS Partitioned Cookies Give Each Site Its Own Jar

What are CHIPS partitioned cookies?

Browsers keep CHIPS partitioned cookies in a separate jar for every top-level site, so the cookie a support widget sets while embedded on retail.example is unreadable to that same widget embedded on news.example. CHIPS stands for Cookies Having Independent Partitioned State, and it runs on one opt-in attribute: add Partitioned to the Set-Cookie header and the browser stores the cookie under two keys instead of one, the host that set it plus the top-level site it was set under. Add it to any cross-site cookie confined to a single top-level site, such as a chat session, a CDN load balancer hint, or a saved map location.

Double-keying is what separates CHIPS from the plain third-party cookie, which travels with the embed everywhere and powers cross-site tracking. A partitioned cookie cannot leave the site it was born on, so an embed gets a fresh identifier per top-level site and nothing to join across them. If the two categories blur together, start with first-party and third-party cookies.

What does the Partitioned attribute require?

The Partitioned attribute requires Secure, and browsers throw away any partitioned cookie that arrives without it. The CHIPS explainer at the W3C Privacy Community Group instructs implementers: "User agent must reject any cookie set with Partitioned that does not also include the Secure." Google's Privacy Sandbox documentation repeats it for developers: "Partitioned cookies must be set with Secure." The IETF draft, draft-cutler-httpbis-partitioned-cookies-01 of 10 November 2022, gives the reason in its security considerations: "This proposal takes the opportunity of defining the semantics of a new cookie attribute in order to require the Secure attribute, restricting this feature to secure protocols."

The Path=/ in every official example comes from a second rule, carried by the __Host- name prefix and not by Partitioned itself. RFC 6265bis, draft 22 of December 2025, section 4.1.3.2 defines it: "If a cookie's name begins with a case-sensitive match for the string __Host-, then the cookie will have been set with a Secure attribute, a Path attribute with a value of /, and no Domain attribute." Name the cookie __Host-something and the browser enforces Path=/ for you, rejecting anything else. The CHIPS explainer recommends the prefix without demanding it: "Although it is not required, it is still recommended to still include the __Host- prefix." Browsers that ignore Partitioned still enforce __Host-, so the prefix buys host binding on clients that have never heard of CHIPS.

SameSite is the third piece. The explainer says user agents may accept Partitioned only when SameSite is None, and a cookie built to work inside a cross-site frame needs SameSite=None regardless. See the beginner's guide to browser cookies for how the attributes interact.

What exactly is the partition key?

The partition key is the site of the page in the address bar, not the site of the embed. The CHIPS explainer defines it precisely: "A cookie's partition key is the site (i.e. scheme and registrable domain) of the top-level URL the browser was visiting at the start of the request to the endpoint that set the cookie." Two words there do real work. "Site" means the registrable domain, so support.shoppy.example and checkout.shoppy.example share a partition. "Scheme" puts the protocol in the key, so http://shoppy.example and https://shoppy.example do not.

Chrome adds one more field. Chrome Platform Status records the change: "Chrome 128 adds a cross-site ancestor bit to the keying of the partitioned cookie's CookiePartitionKey." That bit records whether a cross-site frame sits between the top-level document and the frame making the request, which stops an embed from reaching the top-level site's own partitioned cookies through a nested iframe. From Chrome 128 the key is a triple: scheme, registrable domain, ancestor bit.

What does a real Set-Cookie header look like?

A partitioned cookie is one ordinary Set-Cookie header carrying four attributes. This is the example Google's Privacy Sandbox documentation and MDN both publish, character for character:

Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;

That response has to arrive over HTTPS, since Secure and __Host- both demand a secure origin. On a later request to the same embed under the same top-level site, the browser sends the cookie back bare:

Cookie: __Host-example=34d8g

Navigate to a different top-level site and that second header disappears. The embed sees no cookie and mints a new value, which is the whole point.

Which browsers accept the Partitioned attribute?

Three engines accept it. These versions come from MDN's browser compatibility data for Partitioned.

MDN marks partitioned cookies as Baseline newly available since December 2025. Clients that do not recognise the attribute ignore it and treat the cookie as an ordinary SameSite=None cookie, so your fallback is whatever that browser does with third-party cookies. In Safari the fallback is nothing, because Intelligent Tracking Prevention blocks them outright and caps script-set cookies through the Safari 7 day cookie limit.

How much can one embed store in a single partition?

Chrome caps a partition at 180 cookies and 10 KB per embedded site. Its CHIPS documentation states it directly: "Chrome has a limit of maximum 180 cookies per partition that cannot exceed 10 KB per-embedded-site." The byte cap binds first for most embeds, so the number to check is:

partition bytes used = number of cookies x average bytes per cookie

An embed storing 20 cookies that average 500 bytes each uses 20 x 500 = 10,000 bytes, hitting the 10 KB ceiling with 160 of the 180 slots free. Past the byte budget the browser evicts, so budget by size, not by count.

Is Chrome still deprecating third-party cookies?

No. Google's most recent Privacy Sandbox announcement, "Update on Plans for Privacy Sandbox Technologies" by Anthony Chavez, VP of Privacy Sandbox, dated 17 October 2025, refers back to the earlier decision "that Chrome will maintain our current approach to offering users third-party cookie choice in Chrome." No browser-wide deprecation is scheduled and no new prompt is coming. Chrome allows third-party cookies in normal browsing and blocks them in Incognito.

The same announcement is why CHIPS is worth building on. It retired the Attribution Reporting API, Protected Audience, Topics, Private Aggregation and Related Website Sets, then singled CHIPS out for the opposite treatment: "CHIPS and FedCM, which improve cookie privacy and security and streamline identity flows respectively, have seen broad adoption, including support from other browsers. We'll continue to support those APIs and evaluate opportunities for future enhancements." Related Website Sets is on the retirement list. CHIPS is not.

What does this mean for your analytics?

Analytics that sets no cookies skips the question. Partitioning solves a problem you only have when a script remembers a visitor through browser storage, so cookieless tracking removes the failure mode instead of isolating it. Flowsery's cookie-free, EU-hosted analytics records sessions and replays without cookies, so there is no partition key to get wrong.

The calculus flips if your product ships a widget that other companies embed. That widget needs state, the top-level site is not yours, and CHIPS keeps it working. Add Partitioned, use the __Host- prefix, keep SameSite=None; Secure, and test the first request in a fresh partition, because that path now runs on every new customer site.

Frequently asked questions

Does the Partitioned attribute need Path=/?

Not from Partitioned itself. The CHIPS explainer, the IETF draft and Google's CHIPS documentation all omit Path=/ from the attribute's requirements. It appears in every official example because those examples use the __Host- prefix, and RFC 6265bis requires __Host- cookies to carry a Path of / and no Domain attribute.

Is the __Host- prefix mandatory for partitioned cookies?

No. The CHIPS explainer says the prefix "is not required" but is "still recommended", so a partitioned cookie without it is accepted. Use it anyway: browsers that ignore Partitioned still enforce the prefix and bind your cookie to the exact host.

Do partitioned cookies still need consent under GDPR?

Yes. Partitioning changes who can read a cookie, not whether one lands on the device. The ePrivacy Directive's consent requirement attaches to storing or accessing information on a user's terminal equipment, and a partitioned cookie does both. Strictly necessary cookies stay exempt either way.

Can a top-level site clear an embed's partitioned cookies?

No. The CHIPS explainer states that top-level sites must not be able to clear third parties' cookies in their partition, since that would let a host site interfere with code inside embedded frames. An embed clears its own partition by sending Clear-Site-Data, which touches only the current top-level site's partition.

How is CHIPS different from Firefox state partitioning?

Firefox partitions third-party cookie storage by default, with no opt-in from the site. CHIPS is an attribute a service adds deliberately, and it applies in first-party and third-party contexts alike. MDN recommends the CHIPS opt-in over state partitioning, because the explicit attribute is the most compatible across browsers.

What replaces CHIPS if an embed needs one cookie across several sites?

The Storage Access API. Related Website Sets used to cover that case by declaring a group of related domains, and Google's 17 October 2025 announcement listed it among the retired technologies. The Storage Access API asks the user for permission to use unpartitioned storage in a cross-site frame, and it is the remaining supported route for shared state.

Does the Partitioned attribute work with SameSite=Lax or SameSite=Strict?

The CHIPS explainer lets browsers accept Partitioned only when SameSite is None, so a Lax or Strict cookie can end up unpartitioned even with the attribute present. The pairing fits the use case, since a partitioned cookie matters inside a cross-site embed, and an embed needs SameSite=None to receive a cookie at all. Set SameSite=None; Secure alongside Partitioned and the question does not come up.

What happens when a partition goes over Chrome's 10 KB cookie limit?

Chrome enforces a cap of 180 cookies and 10 KB per partition for each embedded site, and once storage crosses either line the browser evicts cookies from that partition. The byte cap usually binds first: a handful of cookies averaging a few hundred bytes each can fill 10 KB while dozens of the 180 slots sit empty. Plan around total bytes stored per top-level site, not around how many cookies you set.

Can a partitioned cookie be set over plain HTTP?

Secure blocks it. The Partitioned attribute requires Secure, and the IETF draft names that exact pairing as the reason for defining the new attribute at all, restricting the feature to secure protocols. A Set-Cookie header sent over plain HTTP loses both Partitioned and the cookie carrying it.

What is the cross-site ancestor bit in Chrome's partition key?

From Chrome 128, the partition key gains a third field, alongside scheme and registrable domain, recording whether a cross-site frame sits between the top-level document and the frame that made the request. That ancestor bit stops an embed from reaching the top-level site's own partitioned cookies through a nested iframe. Older Chrome versions and other browsers key partitions on scheme and registrable domain only.