Browser vendors are fundamentally changing how cookies work across sites. The traditional model allowed third-party cookies to track users across the web, enabling both legitimate use cases like single sign-on and problematic tracking practices. As browsers phase out unrestricted third-party cookies, new mechanisms like CHIPS (Cookies Having Independent Partitioned State) provide controlled ways to maintain necessary cross-site functionality while improving privacy.
For domain owners managing multi-site architectures, authentication systems, or embedded content, understanding cookie partitioning determines whether your services continue working as browsers update their policies. The changes affect how you structure domains, set cookie attributes, and design cross-site interactions. Getting ahead of these transitions means your infrastructure adapts smoothly rather than breaking when browser updates arrive.
The Third-Party Cookie Problem and Privacy Sandbox
Third-party cookies set by domains other than the one in the browser's address bar have powered web functionality for decades. When you visit site-a.com and it includes content from site-b.com, site-b.com can set cookies in your browser. Those same cookies are sent back to site-b.com when you visit site-c.com that also embeds site-b.com content, allowing site-b.com to correlate your activity across both sites.
This cross-site correlation enabled tracking networks to build detailed profiles of user behavior. While some uses were beneficial—analytics platforms measuring site performance, authentication providers enabling single sign-on, content delivery networks optimizing delivery—the same mechanism supported pervasive tracking that users found invasive.
Browser vendors responded with increasingly strict cookie policies. Safari and Firefox have blocked most third-party cookies for years. Chrome has announced plans to phase them out, though the timeline has shifted multiple times as the ecosystem adapts. The challenge is replacing third-party cookies for legitimate use cases while preventing the tracking that prompted the changes.
Privacy Sandbox represents Chrome's approach to this transition. It introduces new APIs designed to support specific use cases previously handled by third-party cookies: advertising measurement, fraud prevention, federated identity, and cross-site state management. CHIPS addresses the last category by allowing cookies to work across sites in a partitioned way that prevents cross-site tracking.
How Cookie Partitioning Works
Cookie partitioning changes when browsers send cookies to third-party contexts. Traditionally, cookies set by site-b.com are sent in all requests to site-b.com, regardless of which site triggered those requests. With partitioning, cookies are keyed not just by the domain that set them but also by the top-level site where they were set.
When you visit site-a.com and it embeds content from site-b.com, site-b.com can set a partitioned cookie. That cookie is sent back to site-b.com only when embedded in site-a.com. If you visit site-c.com that also embeds site-b.com, site-b.com receives a different partitioned cookie specific to the site-c.com context. The two cookies cannot be correlated because they exist in separate partitions.
This partitioning breaks cross-site tracking while preserving functionality within each site. An authentication service can maintain session state for its embedded iframe, analytics can track user flows within a site, and CDNs can optimize delivery based on per-site preferences. What disappears is the ability to track users as they move between unrelated sites.
The partition key includes both the scheme and registrable domain of the top-level site. This means cookies partitioned under https://site-a.com are separate from those under http://site-a.com, and cookies under subdomain1.site-a.com share the same partition as subdomain2.site-a.com because they have the same registrable domain.
The Partitioned Attribute and CHIPS
CHIPS introduces a new cookie attribute called Partitioned. When a server sets a cookie with this attribute, it explicitly opts into partitioning:
Set-Cookie: sessionid=abc123; Secure; HttpOnly; SameSite=None; Partitioned
The Partitioned attribute must be used with Secure (cookies only sent over HTTPS) and SameSite=None (cookies sent in third-party contexts). These requirements ensure that partitioned cookies meet baseline security standards and work correctly in cross-site scenarios.
Without the Partitioned attribute, browsers applying cookie deprecation will not send cookies in third-party contexts at all. Sites that need cross-site cookie functionality must explicitly adopt CHIPS to maintain that functionality as browsers phase out traditional third-party cookies.
For domain owners planning transitions, the migration path involves identifying which cookies need cross-site access, adding the Partitioned attribute to those cookies, and verifying that the resulting partitioned behavior meets your use case requirements. Not all cookies need to be partitioned—first-party cookies used only within your own domain continue working without changes.
SameSite, Secure, and Cookie Attribute Interactions
Cookie attributes interact in specific ways that determine when cookies are sent. The SameSite attribute controls cross-site sending behavior with three values: Strict, Lax, and None.
SameSite=Strict prevents cookies from being sent in any cross-site context. These cookies only accompany requests where the top-level site matches the cookie's domain. SameSite=Lax allows cookies in some cross-site contexts, specifically top-level navigation (like clicking a link from another site), but not in embedded contexts like iframes or images.
SameSite=None permits cookies in all cross-site contexts, which is necessary for embedded content that needs cookies to function. However, SameSite=None requires the Secure attribute, meaning the cookie can only be sent over HTTPS connections. This requirement prevents downgrade attacks where an attacker might force HTTP connections to capture cookies.
The Partitioned attribute must be combined with SameSite=None and Secure:
Set-Cookie: data=value; SameSite=None; Secure; Partitioned
This combination explicitly states: "This cookie should be sent in third-party contexts (SameSite=None), only over HTTPS (Secure), and should be partitioned by top-level site (Partitioned)."
Trying to use Partitioned without SameSite=None or Secure will cause browsers to reject the cookie. Understanding these dependencies helps avoid configuration mistakes that silently break functionality.
Domain Cookies vs Host-Only Cookies in Partitioned Contexts
Cookies can be scoped to either a specific host or an entire domain. A host-only cookie applies only to the exact hostname that set it. A domain cookie applies to that hostname and all its subdomains.
When setting a cookie, the Domain attribute controls this scope:
Set-Cookie: data=value; Domain=example.com
This creates a domain cookie that applies to example.com, www.example.com, api.example.com, and any other subdomain. Omitting the Domain attribute creates a host-only cookie that applies only to the specific hostname that set it.
In partitioned contexts, domain scoping interacts with partition keys. A partitioned cookie set by sub1.example.com with Domain=example.com will be sent to sub2.example.com when both are embedded in the same top-level site. The partition key (the top-level site) and the domain scope (example.com) together determine when the cookie is sent.
This behavior allows related subdomains within your infrastructure to share partitioned state when embedded together. However, it also means carefully structuring your domain architecture. If you register a domain and plan to use cookie partitioning across multiple services, consider whether those services should share cookies via domain scoping or remain isolated with host-only cookies. Public Suffix List and Registrable Domains
The Public Suffix List (PSL) defines which domain components constitute a registrable domain versus public suffixes. This matters for cookie partitioning because partition keys use registrable domains, not full hostnames.
A public suffix is a domain under which entities can register subdomains. For .com, the public suffix is com, and example.com is a registrable domain. For .co.uk, the public suffix is co.uk, and example.co.uk is a registrable domain.
Cookie partitioning keys by registrable domain mean that all subdomains of example.com share the same partition when embedded in a given top-level site. Cookies partitioned under sub1.example.com and sub2.example.com are in the same partition because both derive from the registrable domain example.com.
This design prevents cookie scoping from being used to bypass partitioning. Without PSL awareness, an entity could register sub1.shared-hosting-domain.com and sub2.shared-hosting-domain.com and use cookie domain scoping to track users across unrelated sites. By keying partitions to registrable domains, browsers ensure that only related subdomains under the same ownership can share partitioned state.
For operators of shared hosting platforms, this means tenants cannot use cookie partitioning to track across tenant boundaries. Each tenant effectively operates within their subdomain partition, isolated from other tenants even though all share the same registrable domain.
When planning domain architecture for services using partitioned cookies, verify how the PSL classifies your domains. In rare cases, organizations may have TLD-like entries in the PSL (like blogspot.com or github.io), which affects partition key calculation.
First-Party Sets and Related Website Sets
First-Party Sets, now called Related Website Sets (RWS), allow organizations to declare relationships between domains they own. This mechanism lets browsers treat related domains as belonging to the same entity for privacy purposes, even when they have different registrable domains.
A Related Website Set might include example.com, example-cdn.com, and example-analytics.com, all owned by the same organization. By declaring these relationships, the organization can share certain capabilities across the set while maintaining the privacy benefits of domain separation for unrelated entities.
RWS affects cookie behavior in that browsers may allow unpartitioned cookies between domains in the same set, treating them more like first-party cookies than traditional third-party cookies. However, the exact treatment depends on browser implementation and user preferences.
For domain owners managing multiple properties, RWS provides a way to maintain unified identity and state across related domains as third-party cookie restrictions tighten. The declaration requires validation to prevent abuse, you cannot simply claim that your domain is related to another organization's domain without proof of common ownership.
Implementation involves creating a JSON file describing the set and submitting it to browser vendors for inclusion in their RWS lists. The process includes verification of domain control and legitimate relationships between members of the set.
Migration Strategies for Existing Cross-Site Cookie Uses
Migrating to partitioned cookies requires identifying current third-party cookie dependencies and determining appropriate solutions. Start by auditing which cookies your site sets in third-party contexts and what functionality they support.
For embedded content like social widgets, payment processors, or authentication providers, check whether those services have updated to support CHIPS. Many third-party services are actively migrating their implementations to use partitioned cookies. Updating to newer versions of their SDKs or embed codes may automatically adopt partitioned cookies.
For services you control embedded in other sites, update cookie-setting logic to include the Partitioned attribute along with SameSite=None and Secure. Test across different browsers to verify that partitioned cookies maintain necessary functionality. Remember that partitioned cookies cannot correlate user activity across different top-level sites, so functionality relying on cross-site correlation will need redesign.
Some use cases may require alternatives to cookies entirely. Federated identity systems can use the FedCM API, which provides browser-mediated authentication flows without requiring cookies. Analytics and measurement can transition to Privacy Sandbox APIs designed for those purposes, like the Attribution Reporting API.
For domains providing hosting services to customers who embed content across sites, provide clear guidance on cookie partitioning and help customers understand which configurations maintain functionality. Sample code, migration checklists, and testing tools reduce friction in adoption. Analytics and Cross-Site Tracking Alternatives
Analytics platforms traditionally used third-party cookies to track users across properties and build comprehensive behavioral profiles. Cookie partitioning fundamentally breaks this model by isolating cookies per top-level site.
Partitioned cookies allow analytics to track user sessions within a single site but not across different sites. An analytics provider embedded in site-a.com and site-b.com will see separate, unlinked sessions from the same user visiting both sites. This preserves useful within-site analytics while preventing cross-site tracking.
Organizations needing to measure user journeys across their own properties have several options. Related Website Sets can unify tracking across domains under common ownership. First-party analytics deployed on each property can share data server-side using privacy-preserving techniques. Alternatively, migrating to Privacy Sandbox APIs provides measurement capabilities designed specifically for the post-third-party-cookie web.
For site owners using third-party analytics, verify that your analytics provider supports partitioned cookies or has migrated to alternative measurement methods. Most major analytics platforms have published migration guides and updated their tracking scripts to work in the new privacy model.
Custom analytics implementations require updating cookie-setting code to include Partitioned, SameSite=None, and Secure attributes. Verify that reporting and analysis systems account for partitioned cookie behavior, understanding that user identity is now scoped per-site rather than globally.
Testing Partitioned Cookie Implementations
Browser developer tools include features for testing cookie behavior. In Chrome, opening DevTools and navigating to Application > Cookies shows all cookies for the current site, including their attributes. The Partition Key column displays the top-level site for partitioned cookies.
You can set experimental flags in Chrome to enable or modify cookie partitioning behavior:
chrome://flags/#test-third-party-cookie-phaseout
This flag allows testing how your site behaves when third-party cookies are blocked entirely, helping identify dependencies before the full rollout of cookie restrictions.
Network inspection in DevTools shows which cookies are sent with each request. Look for the Cookie header in request details to verify that partitioned cookies are sent in appropriate contexts and that unpartitioned cookies are not erroneously sent in third-party contexts.
For cross-site testing, create test pages on different domains that embed your content. Verify that partitioned cookies set in one top-level site context remain isolated from cookies in other contexts. Open multiple test sites simultaneously and check that cookie values differ between them.
Automated testing frameworks can verify cookie behavior programmatically. Selenium and Playwright support cookie inspection and manipulation, allowing you to write tests that verify partitioned cookie behavior across different scenarios.
SSL Certificates and Secure Cookie Requirements
The Secure attribute requirement for partitioned cookies means your entire cross-site cookie infrastructure must use HTTPS. This includes not just your main site but any embedded content that sets partitioned cookies.
For organizations transitioning to partitioned cookies, verify that all domains involved have valid SSL certificates and are accessible over HTTPS. Mixed content policies in browsers prevent secure pages from loading insecure resources, so any HTTP-only endpoints that set cookies will not function in secure contexts. Certificate management becomes more important when operating multiple domains or subdomains that share partitioned cookie state. Wildcard certificates can cover multiple subdomains under a single certificate, simplifying management. Alternatively, multi-domain certificates cover distinct domains under one certificate.
For operators of email or other non-web services, note that Secure cookie requirements only apply to cookies sent over HTTP(S). Email protocols like SMTP, IMAP, and POP3 use different authentication mechanisms and are not affected by web cookie partitioning. However, web-based email interfaces that embed content from other domains may need partitioned cookies for features like inline attachment previews or embedded calendars. These webmail interfaces should follow the same partitioned cookie practices as other web applications.
Domain Architecture Considerations
When designing domain structures for services using partitioned cookies, several architectural patterns emerge. Organizations with tightly coupled services may consolidate under a single registrable domain, using subdomains to separate services. This allows cookie domain scoping to share partitioned state across services when embedded together.
Alternatively, using distinct registrable domains for different services provides stronger isolation but requires explicit cross-domain communication mechanisms. If services need shared authentication or state, consider Related Website Sets or server-side communication patterns rather than relying on cookie sharing.
For content delivery networks or shared infrastructure, host-only cookies prevent one tenant's cookies from being visible to other tenants on different subdomains. Even within partitioned contexts, domain-scoped cookies could potentially leak information between tenants if not carefully managed.
Think about the implications of partition keys when designing iframe-based architectures. If your service is embedded in multiple customer sites, each customer site creates a separate partition. State must be managed per-partition, not globally. For features requiring cross-site aggregation, server-side state management becomes necessary.
Performance and Storage Implications
Cookie partitioning increases the number of cookie stores browsers must maintain. Each partition requires separate storage, potentially multiplying the number of cookies for frequently embedded services. While individual cookie size limits remain the same, the total storage for a single cookie name across all partitions can grow substantially.
Be mindful of cookie size and count, particularly for services embedded across many sites. Each partition maintains its own copy of every partitioned cookie, so a cookie set on hundreds of sites creates hundreds of partition-specific copies. Keep cookie payloads small and only set partitioned cookies when cross-site functionality genuinely requires them.
Browser cookie limits apply per partition, not globally. A single domain can have up to 180 cookies per partition in Chrome, but across 100 partitions, that is 18,000 total cookies associated with the domain. While this scale is unusual, high-traffic embedded services should monitor storage usage.
Cookie transmission affects performance. More cookies mean larger HTTP headers, increasing request overhead. In partitioned contexts, be particularly careful about automatically setting numerous tracking or analytics cookies that may not be necessary for core functionality.
Future Evolution and Ongoing Standards Work
Cookie partitioning represents one phase in ongoing web privacy evolution. Browsers continue refining policies, and new APIs emerge to handle use cases that third-party cookies previously addressed. Staying current with browser announcements and standards development helps anticipate future changes.
The Privacy Community Group within the W3C coordinates much of this work, publishing proposals and gathering feedback on privacy-preserving web technologies. Following their discussions provides early insight into upcoming changes that may affect your cookie architecture.
Browser vendors publish deprecation timelines and migration resources. Chrome's Privacy Sandbox site, Safari's WebKit blog, and Firefox's developer documentation all include information about cookie policies and recommended practices. Subscribing to these resources ensures you receive updates as policies evolve.
Industry-specific guidance also emerges from trade organizations and technology communities. Payment processors, advertising platforms, and authentication providers often publish joint recommendations for their sectors, reflecting collective understanding of how new privacy mechanisms affect specific use cases.
Practical Next Steps for Domain Owners
Begin by auditing your current cookie usage. List all cookies set by your domains, noting which are used in third-party contexts. Determine whether each cookie requires cross-site functionality or serves only first-party purposes.
For cookies needing cross-site access, implement the Partitioned attribute along with SameSite=None and Secure. Verify that your infrastructure supports HTTPS for all domains setting partitioned cookies. Test the partitioned behavior to ensure functionality remains intact.
Update documentation and developer guides to reflect partitioned cookie requirements. If you provide embed codes or SDKs for others to integrate, include examples showing proper cookie attribute configuration. Warn developers about behaviors that will break as third-party cookies disappear.
Monitor browser announcements about third-party cookie deprecation timelines. When browsers announce testing phases or rollout schedules, participate in those programs to identify issues before they affect all users. Early testing reveals edge cases and compatibility problems while you still have time to address them.
Consider long-term architectural changes beyond just adding the Partitioned attribute. Evaluate whether your domain structure optimally supports partitioned cookie behavior or whether consolidation or splitting of services would improve functionality and maintainability.
Cookie partitioning represents a significant shift in how the web handles cross-site state. The transition requires thoughtful planning and testing, but the result is a more privacy-respecting web that still supports legitimate cross-site functionality. Domain owners who proactively adopt these changes position their infrastructure for success in the evolving web privacy landscape.
.png&w=2048&q=75)
