Partitioned cookies, also known as Cookies Having Independent Partitioned State (CHIPS), allow developers to opt a cookie into a separate storage jar for every top-level site a user visits. This prevents third-party services from tracking users across unrelated websites while still allowing embedded content to function correctly. This technology is a core component of the Privacy Sandbox initiative, designed to balance user privacy with technical utility.
What is Partitioned Cookies?
Partitioned cookies change how browsers store and retrieve third-party cookies. Historically, third-party cookies were stored using a single "host key" based on the domain that set the cookie. This allowed a service like 3rd-party.com to access the same cookie whether the user was on site-a.com or site-b.com, enabling cross-site tracking.
CHIPS introduces "double-keying." A partitioned cookie is tied to both the third-party domain and the top-level site where the user is currently browsing. This ensures that the cookie set on site-a.com cannot be read when the user visits site-b.com, effectively isolating user data per site.
Why Partitioned Cookies matters
- Protects user privacy. By isolating cookies to the top-level site, it blocks the ability of third-party services to build tracking profiles based on browsing history.
- Maintains essential functions. It allows legitimate third-party embeds, such as maps or chat widgets, to remember user states without enabling cross-site tracking.
- Increases security. Partitioned cookies reduce the impact of CSRF and XSS attacks because the browser only sends the cookie when the user is on the specific top-level site that created it.
- Ensures browser compatibility. As browsers phase out traditional third-party cookies, [CHIPS became available across all latest devices and browser versions in December 2025] (MDN).
- Provides a secure opt-in. Unlike some older methods that partitioned all cookies by default, the CHIPS model uses an explicit attribute, preventing unexpected bugs for legacy servers.
How Partitioned Cookies works
Partitioning creates a new storage mechanism for the browser. Here is the process for implementing and retrieving a partitioned cookie:
The implementation process
- The third-party service sends a
Set-CookieHTTP header. - The header must include the
Partitionedattribute. - The browser generates a partition key based on the scheme (e.g., https) and the registrable domain of the top-level site.
- The browser stores the cookie using both the host key and this new partition key.
The technical requirement
To successfully use CHIPS, the Set-Cookie header must follow a specific format. It must include the Partitioned and Secure attributes. The __Host- prefix is also highly recommended to bind the cookie to the specific hostname.
Example of a valid header:
Set-Cookie: __Host-example=12345; SameSite=None; Secure; Path=/; Partitioned;
Best practices
Always use the Secure attribute. Partitioned cookies will only be accepted and sent over secure protocols. If Secure is missing, the browser will ignore the cookie.
Include the __Host- prefix. This binds the cookie to the hostname and prevents it from being shared with subdomains. It also requires the cookie to be set with a Path=/.
Check for browser support. [CHIPS is supported by default in Chrome 114 and higher] (Chrome Status), but older versions may require the Storage Access API or Related Website Sets as alternatives.
Monitor memory usage. To prevent denial of service risks, developers should be aware that [user agents may limit partitioned cookies to 10 kilobytes per top-level partition] (IETF Draft).
Common mistakes
Mistake: Forgetting the Partitioned attribute in the Set-Cookie header.
Fix: Ensure Partitioned is included; otherwise, the cookie will be treated as a standard third-party cookie and may be blocked.
Mistake: Attempting to share a partitioned cookie across two different top-level sites. Fix: Use Related Website Sets if you need to share state across multiple domains owned by the same organization.
Mistake: Expecting partitioned cookies to work on insecure (HTTP) sites.
Fix: Transition all resources to HTTPS, as the Secure flag is a requirement for CHIPS.
Mistake: Using a global cookie limit for partitioned storage. Fix: Recognize that [partitioned cookies should not be subject to the 180 global per-domain cookie limit] (IETF Draft) to avoid cross-partition tracking leaks.
Examples
Scenario 1: Embedded Chat Widget
A retail site embeds a support chat from a third-party provider. The chat provider sets a partitioned cookie to remember the user's chat history while they browse the retail site. If the user moves to a different retail site that uses the same chat provider, the provider cannot see the chat history from the first site.
Scenario 2: Subresource CDN
A CDN uses cookies to manage load balancing for high-traffic assets. By using the Partitioned attribute, the CDN can maintain session state for a specific visitor on a specific site without being able to track that visitor as they move to other websites that use the same CDN.
Partitioned Cookies vs Related Website Sets
| Feature | Partitioned Cookies (CHIPS) | Related Website Sets (RWS) |
|---|---|---|
| Goal | State isolation per site | State sharing across related sites |
| When to use | Isolated widgets (maps, chat) | Sites with different domains (e.g., .com and .co.uk) |
| Privacy Risk | Very Low | Moderate (allows limited tracking) |
| Developer Input | Cookie attribute | Official site submission |
FAQ
Can I set partitioned cookies via JavaScript?
Yes. You can set them using document.cookie. You must include the same required attributes as the HTTP header: ; Secure; SameSite=None; Partitioned;.
How does CHIPS differ from Firefox's default partitioning? Firefox's state partitioning mechanism partitions all third-party cookies by default. CHIPS is an opt-in model. Using the CHIPS opt-in is recommended as it provides better compatibility for third-party services that may not be designed for automatic partitioning.
Will partitioned cookies be cleared when a user clears their site data?
Yes, but with nuances. When a site sends a Clear-Site-Data header for "cookies," the browser should only clear cookies where the partition key matches the current top-level site to prevent cross-site identity persistence.
What happens if a user navigates to the third-party site directly?
If a user visits the third-party service as a top-level site (e.g., visiting 3rd-party.com directly), the partitioned cookie set while it was an embed will not be sent. The browser will treat it as a separate context.
How do I test if my cookies are partitioned? You can use Chrome DevTools. Navigate to Application > Storage > Cookies and click on the third-party origin. Look for the "Partition Key" column to verify the top-level site is listed correctly.
