Partitioned Cookies (CHIPS): Do You Still Need Consent?

What CHIPS actually is

CHIPS stands for Cookies Having Independent Partitioned State. It lets you opt a cross-site cookie into partitioned storage, a separate cookie jar per top-level site, using a new attribute on the Set-Cookie header. The MDN reference shows the shape:

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

The Partitioned attribute is the opt-in. It must be paired with Secure, and cross-site use means SameSite=None; the __Host- prefix is recommended. As of December 2025 the feature is available across current browser versions. So this isn't a proposal anymore; it's something your vendors may already be setting.

What partitioning fixes

The cookie is double-keyed by the top-level site the browser was visiting when it was set. Concretely, an embedded widget on your-site.com can keep state in a cookie, but the same third party embedded on other-site.com gets a different, isolated jar and can't read the one from your site. That's the whole point: it blocks the cross-site tracking that unpartitioned third-party cookies enabled, while still letting legitimate embedded things work, an embedded map remembering its zoom, a chat widget holding a conversation, as the Privacy Sandbox CHIPS documentation describes.

Why it exists now, and the plot twist

CHIPS came out of the effort to make the web work without third-party cookies, and its origins are in the Privacy Community Group's CHIPS proposal. Then the ground shifted: Chrome reversed course and kept third-party cookies rather than deprecating them, which we covered in what Google's Privacy Sandbox wind-down means for consent. That could make CHIPS look pointless. It isn't. Partitioned cookies still ship, and they're the forward-compatible way to run embedded cross-site cookies. They also keep working where third-party cookies are already blocked, in Safari under ITP, in Firefox, and inside the in-app WebViews social apps use.

The consent question, answered plainly

Here's the part teams get wrong. A partitioned cookie is still a cookie. Article 5(3) of the ePrivacy Directive is about storing or accessing information on a user's device, and the EDPB's Guidelines 2/2023 make clear the rule is technology-agnostic. Partitioning changes who can read the cookie. It does not change the fact that you stored something on the device. If the cookie is non-essential, an analytics, advertising, or marketing cookie, you still need consent before you set it, whether or not it carries the Partitioned attribute.

Say it clearly: CHIPS is a technical control, not a legal basis. It reduces cross-site tracking, which is good for your users and good for your risk posture, but it doesn't move a tracking cookie into the exempt column.

Where it does help your compliance story

Partitioning isn't legally irrelevant, though. For a genuinely functional embed, a support chat widget restoring a session, an embedded map remembering state, the fact that the cookie is scoped to your site and can't be read cross-site strengthens the case that it's a contained, non-tracking cookie. That supports the strictly-necessary or functional categorization you'd have argued for anyway. What it can't do is upgrade an analytics or ad cookie into an essential one. Categorize by purpose, not by attribute; the framework is in our guide to cookie categories.

Two limits and a non-use

Partitioned cookies still obey normal cookie constraints, including Chrome's expiry cap on cookies set through JavaScript, and they're cleared when the user clears the top-level site's data, so they're not a durable identifier store. Two things they don't help with. First-party analytics cookies you set on your own domain were never the cross-site tracking problem, so partitioning changes nothing there; a non-essential first-party cookie still needs consent, and partitioning gives you no new argument for it. And a cookie set for cross-site or cross-device profiling can't be partitioned and still do its job, because partitioning is exactly what severs the cross-site link. If a vendor tells you its tracking cookie is now privacy-safe because it's partitioned, check whether the tracking still works the way they're selling it, because those two claims are usually in tension.

How to check what's actually partitioned

You don't have to guess. In Chrome DevTools, open Application, then Cookies, and look at the Partition Key column: a partitioned cookie shows the top-level site it's bound to, while an unpartitioned one leaves it blank. That's the fastest way to audit which embeds have adopted the attribute and which are still setting old-style cross-site cookies. The usual suspects to check are third-party chat widgets, embedded video players, payment iframes, and map widgets, since those are the embeds with a real reason to persist state inside your site.

Two adjacent mechanisms get confused with CHIPS, so keep them straight. The Storage Access API lets an embedded frame request access to its own unpartitioned cookies after a user gesture. Related Website Sets lets a company declare that a small group of its domains count as one first party for cookie purposes. Neither one is a consent mechanism, and neither exempts a non-essential cookie from the banner. They change access rules between sites; they say nothing about your Article 5(3) duty to ask first.

Practical steps

1. Inventory which third-party embeds set cross-site cookies on your site, and check whether they've adopted the Partitioned attribute.
2. Keep consent gating in place for every non-essential cookie, partitioned or not.
3. Use partitioning as supporting evidence for a functional categorization, never as the reason for it.
4. Don't confuse adjacent mechanisms. The Storage Access API and Related Website Sets solve related access problems; none of them is a consent exemption.

CookieBeam's scanner flags the cross-site cookies your embeds set and their attributes, so you can see what's partitioned and what still needs gating, and it holds the non-essential ones until consent. For the wider picture of where third-party cookies actually stand in Chrome now, see third-party cookies aren't dead in Chrome and our explainer on first-party versus third-party cookies.