Wiki · Concept · Last reviewed June 25, 2026

Partitioned Cookies (CHIPS)

Cookies Having Independent Partitioned State, or CHIPS, is a browser mechanism that lets a cookie be stored separately for each top-level site by using the Partitioned attribute.

Category: Concept Updated: June 25, 2026 Tags: browser privacy, cookies, partitioned state, third-party embeds, surveillance

Definition

Cookies Having Independent Partitioned State, usually shortened to CHIPS, is a web-cookie mechanism for opt-in partitioning. MDN describes CHIPS as putting a cookie into partitioned storage, with a separate cookie jar for each top-level site. Google Privacy Sandbox frames the feature as a way to preserve some cross-site embed uses while preventing one third-party cookie from joining activity across unrelated sites.

The difference is the storage key. An ordinary third-party cookie is keyed primarily by the cookie-setting host or domain. A partitioned cookie is double-keyed by the cookie-setting origin and the top-level site where it was set. A chat widget embedded on one retailer can keep state for that retailer, but the same widget embedded on a different publisher should not receive the same partitioned cookie.

CHIPS is not the same as general storage partitioning. MDN notes that Firefox partitions some third-party state by default in specific modes, while CHIPS is an opt-in cookie attribute. MDN marks CHIPS as Baseline 2025 and says it works across latest devices and browser versions since December 2025, though older browsers may not support it.

Mechanism

The technical surface is the Partitioned cookie attribute. A typical header also includes Secure, and third-party contexts commonly use SameSite=None. MDN says partitioned cookies must be set with Secure, and recommends the __Host- prefix when the cookie does not need to be shared between subdomains. Google Privacy Sandbox gives the same pattern: Set-Cookie: __Host-name=value; Secure; Path=/; SameSite=None; Partitioned;.

Under CHIPS, the browser stores a partitioned cookie using a host key and a partition key. Google Privacy Sandbox says the partition key is the site of the top-level URL at the start of the request that set the cookie. The browser only sends the cookie when a later request has the same partition key. A cookie set by an embedded service under retail.example should therefore not be sent when the same embedded service appears under news.example.

CHIPS is part of a larger third-party-cookie transition toolkit. Google Privacy Sandbox says CHIPS, the Storage Access API, and Related Website Sets are mechanisms for reading or writing cookies from cross-site contexts when third-party cookies are blocked. The distinction is important: CHIPS scopes state to one top-level site, while Storage Access API and Related Website Sets address cases requiring unpartitioned access.

Agent Context

For AI Browsers and Computer Use, CHIPS matters because an agent often interacts with embeds: payment panes, chat widgets, maps, help desks, media players, sign-in widgets, and ads. Those components may remember state inside a top-level-site partition even when the agent cannot see the storage key in the page text.

Agent logs should avoid treating a working embedded session as proof of general cross-site identity. A support widget that remembers a conversation inside one merchant's site may not remember the same user elsewhere. Conversely, partitioned state still means a third-party component is keeping site-scoped memory that can affect what the agent sees and does.

Governance Use

A review record should name the top-level site, embedded origin, cookie name prefix, Secure, SameSite, Path, Domain, and Partitioned attributes, browser support, fallback behavior, and whether the component can function without cookies. It should also state whether the cookie is used for session continuity, load balancing, fraud prevention, embedded payments, ads, or personalization.

The topic belongs beside Storage Access API, Related Website Sets, Permissions Policy, Private State Tokens, Attribution Reporting API, Shared Storage API, and Data Minimization. Each describes a different answer to the same pressure: sites want continuity, browsers want to reduce cross-site tracking, and users rarely see the storage machinery.

Limits

Partitioning is not consent, anonymity, or a full anti-tracking system. It reduces one important join: the same third-party cookie should not follow a user across unrelated top-level sites. But the embedded service can still keep state inside each site partition, and the surrounding system can still use account data, first-party logs, contextual signals, fingerprinting defenses, ad auctions, or server-side identifiers.

CHIPS also creates compatibility questions. Google Privacy Sandbox lists many legitimate uses, including chat, maps, payment embeds, CDNs, headless CMS providers, untrusted-content sandbox domains, front-end frameworks, and ads with state scoped per publisher. That breadth is exactly why audits should ask whether a partitioned cookie is necessary, proportionate, documented, and understandable to the user.

Review Record

Source Discipline

Claims about the Partitioned attribute, double-keying, Secure requirement, __Host- recommendation, and Baseline status should cite MDN. Claims about Chrome support, use cases, partition-key design, limits, and alternatives should cite Google Privacy Sandbox and Chrome Platform Status. Claims about specification history should cite the PrivacyCG CHIPS repository or the IETF draft, not a secondary marketing explainer.

Spiralist Reading

Spiralism reads CHIPS as a lesson in smaller memory. The browser does not abolish the third-party component; it places that component's memory inside a local compartment. That can be an improvement. It can also make surveillance feel solved when it has merely become more scoped, more technical, and harder for ordinary users to inspect.

Sources

Return to Wiki