If your product still relies on cookies in embedded contexts, 2026 is the year to stop treating browser privacy changes as a vague future problem.
The practical path is getting clearer. CHIPS (Cookies Having Independent Partitioned State) gives teams a way to keep legitimate cross-site embeds working without falling back to old-school tracking behavior. And for companies that genuinely operate across multiple related domains, Related Website Sets (RWS) and the Storage Access API are becoming part of the real implementation conversation.
In other words, the cookie story is no longer just about what browsers are taking away. It is about learning the new primitives that replace the old assumptions.
TL;DR
For web teams in 2026, the default mental model should be simple: if a third-party or service domain only needs state scoped to a single top-level site, use partitioned cookies with CHIPS. If you need limited identity or cookie continuity across multiple related domains owned by the same organization, evaluate Related Website Sets plus the Storage Access API. Teams that keep shipping as if all cross-site cookies behave the same are going to hit subtle auth, embed, checkout, analytics, and support-widget failures.
Table of contents
- Why this matters now
- What CHIPS actually changes
- When CHIPS is the right answer
- When you need Related Website Sets instead
- A practical implementation example
- Migration mistakes I expect teams to make
- How product and engineering teams should plan for this
- Final takeaway
- FAQ
Why this matters now
The old model was easy to abuse because it was easy to build around. If you embedded the same third-party resource on multiple sites, that resource could often read the same cookie everywhere. That made some legitimate experiences convenient, but it also made cross-site tracking trivial.
What is changing in 2026 is that the replacement options are maturing enough that product teams can no longer claim the platform is too vague to act on.
A few reasons this has become timely:
- Chrome has documented CHIPS as the privacy-preserving route for cross-site cookie use cases like chat embeds, maps, payment widgets, CDN balancing, and headless CMS integrations.
- MDN marks partitioned cookies as Baseline newly available since December 2025, which is important because it changes the support conversation from experimental curiosity to real roadmap input.
- Multi-domain businesses still need flows like shared sign-in, shopping carts, and preferences across related sites, which is exactly where Related Website Sets enters the picture.
This is the pattern I keep seeing: teams understand that third-party cookies are fragile, but many still do not know which replacement primitive maps to which business problem.
That gap matters more than ever because cookie bugs in 2026 are often not catastrophic in development. They are subtle. A support widget loses conversation state only on one brand domain. A checkout provider works on the marketing site but not the country-specific domain. A sandboxed asset domain fails to preserve session-specific behavior. These are nasty problems because they look random until you understand the browser storage model behind them.
What CHIPS actually changes
CHIPS stands for Cookies Having Independent Partitioned State. The idea is straightforward: a cookie can be stored in a way that is not just keyed by the cookie-setting origin, but also by the top-level site where it was set.
That means an embedded third-party service can keep state, but only within the context of the site where that state was created.
Historically, an embedded service at something like support.chat.example could set a cookie and then read that same cookie whenever it appeared on many unrelated sites. With CHIPS, the storage is partitioned. A cookie set while the service is embedded on retail.example is not automatically the same cookie available when that service appears on news.example.
That is the entire point. The browser still allows legitimate state, but it cuts off the broad cross-site reuse that enabled tracking.
The cookie attribute looks like this:
unknown nodeA few implementation details matter:
Partitionedis the key attribute.Secureis required.SameSite=Noneis typically required for cross-site usage.- Using the
__Host-prefix is strongly recommended when appropriate because it tightens the cookie scope.
A JavaScript example looks like this:
unknown nodeThe main benefit is that you can still build embedded experiences without smuggling in an unpartitioned identity layer.
When CHIPS is the right answer
This is where a lot of teams overcomplicate things. In many cases, CHIPS is not a compromise. It is the correct architecture.
Use CHIPS when your embedded service needs state that should remain specific to the top-level site where it is used.
Good examples include:
- live chat widgets
- embedded maps
- payment components
- embedded customer portals
- headless CMS preview or authoring helpers
- service domains that support one app but should not share identity across unrelated sites
- CDN or media infrastructure that needs request-scoped configuration
Let us say you run multiple client sites and use the same support provider. It is perfectly reasonable for the support widget to remember state within each client site, but it should not silently carry the same identity across every unrelated publisher or store where it appears.
That is why CHIPS is such a useful primitive. It preserves the product behavior you actually need while matching the privacy boundary users increasingly expect.
It also creates a healthier engineering discipline. Once teams stop assuming a universal third-party cookie jar, they are forced to model state more intentionally. That usually leads to cleaner boundaries between:
- site-specific session state
- shared organization-level identity
- analytics identifiers
- user preferences
- infrastructure metadata
That cleanup is not just about compliance or privacy messaging. It reduces accidental coupling.
When you need Related Website Sets instead
CHIPS is not a silver bullet because some organizations genuinely do operate multiple related domains that need controlled continuity.
Think about cases like:
brandx.comandbrandx.co.uk- a main product domain and a separate billing domain
- a company with separate country sites
- app domains such as
mail-brandx.comandcalendar-brandx.com - a security sandbox or user-content domain controlled by the same organization
In those cases, a partitioned cookie per top-level site may be too strict. You may need limited cross-site cookie access for a user-facing reason such as sign-in continuity or remembering an in-progress booking flow.
That is the space for Related Website Sets.
RWS lets an organization declare relationships among domains so browsers can make more informed decisions about when limited cross-site data access is appropriate. It is not a free pass to rebuild old tracking behavior. It is a narrower mechanism for a narrower problem: related domains under common control with legitimate shared experiences.
The important architecture distinction is this:
- CHIPS is about preserving state within a top-level site boundary.
- RWS plus Storage Access API is about carefully allowing some state across related top-level sites.
If your product requirement is, “our embedded service should work independently on every site,” that sounds like CHIPS.
If your product requirement is, “our company runs several related sites and users expect a shared signed-in experience,” that sounds like RWS territory.
Teams get into trouble when they try to use one tool to solve the other tool's problem.
A practical implementation example
Imagine a business with this setup:
shop.examplefor the storefrontsupport.examplefor help contentpay.examplefor hosted checkout componentsassets-examplecdn.comfor media and UI assets
Now imagine two separate needs:
1. Embedded checkout state
If pay.example is embedded inside shop.example, and the checkout component only needs state tied to that shopping session on that storefront, CHIPS is probably enough.
Example server header:
unknown nodeThe embedded checkout can preserve state on shop.example, but that cookie is not broadly reusable elsewhere.
2. Shared sign-in across company-owned domains
If the user moves between shop.example and support.example and the company wants limited continuity for signed-in experiences, RWS and Storage Access API become more relevant.
A simplified client-side access request might look like this:
unknown nodeThat is not a full implementation, but it illustrates the model shift. Access is becoming more explicit, contextual, and purpose-driven.
This matters for architecture reviews. You should stop asking, “How do we keep third-party cookies working?” and start asking:
- Is this state supposed to be site-scoped or organization-scoped?
- Is the embedded service third-party in infrastructure only, or third-party in business relationship too?
- Does the user expect continuity across these domains?
- Can we redesign the flow so that we need less shared cookie state in the first place?
Those questions lead to better systems than trying to preserve a legacy cookie assumption forever.
Migration mistakes I expect teams to make
I think a lot of teams are about to repeat the same pattern we saw with CORS, SameSite, and SPA auth: they will treat a platform shift as a last-mile implementation detail instead of an architectural change.
Here are the mistakes I would actively watch for.
Mistake 1: assuming “embedded” means “needs shared identity”
It often does not. A support widget, map, payment frame, or media tool may only need session state within the current site. If that is true, CHIPS is cleaner and safer than trying to preserve shared identity.
Mistake 2: mixing analytics needs with product needs
Some teams blur together legitimate product state and legacy tracking expectations. That leads to the wrong design. Separate these concerns early. The browser certainly will.
Mistake 3: not testing top-level site boundaries explicitly
You need tests that vary the top-level domain, subdomain, and embedding context. Cookie bugs in this space often pass local testing and then fail in production across regional domains or white-label deployments.
Mistake 4: treating browser support as a hand-wavy excuse
MDN's Baseline signal for partitioned cookies changes the calculus. You still need compatibility planning, but “this is too early” is no longer a serious default position for many products.
Mistake 5: keeping auth and embed teams disconnected
This topic crosses frontend, platform, auth, and product ownership. If your widget team and identity team make separate assumptions, users will find the seams.
How product and engineering teams should plan for this
Here is the pragmatic playbook I would use.
Audit every cross-site cookie dependency
Make a simple inventory:
- what domain sets the cookie
- where the cookie is read
- whether the context is first-party or embedded
- whether the state truly needs to follow the user across multiple top-level sites
- what breaks if the cookie becomes partitioned
This exercise usually reveals that some “critical” shared cookies are actually lazy design leftovers.
Classify each dependency
Create three buckets:
- site-scoped state → candidate for CHIPS
- organization-scoped continuity → candidate for RWS plus Storage Access API
- legacy tracking or vague convenience → likely something to redesign or remove
That classification makes roadmap decisions much easier.
Add real environment tests
Do not stop at localhost. Test with:
- staging domains that mimic production topology
- separate country or brand domains
- embedded iframe contexts
- signed-in and signed-out flows
- browser privacy settings that stress the new model
Coordinate with business stakeholders
This is not just technical debt. It affects conversion, support quality, localization, identity, and trust. Explain the tradeoff clearly: privacy-preserving state is still possible, but the implementation has to reflect the actual relationship between domains.
Prefer explicitness over magic
The broad theme in modern browser privacy features is that implicit cross-site behavior keeps disappearing. Teams that succeed are the ones that move toward:
- explicit storage boundaries
- explicit access requests
- explicit declarations of related domains
- explicit fallbacks when access is unavailable
That is a healthier long-term model anyway.
Final takeaway
CHIPS and Related Website Sets are not niche browser trivia anymore. They are becoming core architecture decisions for modern web teams.
If your product includes embedded services, third-party components, service domains, regional domains, or multi-brand experiences, you need to decide what kind of state you are actually preserving and why.
My view is that the winners in 2026 will not be the teams trying hardest to preserve the old third-party cookie world. They will be the teams that map each use case to the right privacy-era primitive.
Use CHIPS when state should stay scoped to a single top-level site.
Use Related Website Sets plus Storage Access API when a company-owned multi-domain experience genuinely needs limited continuity.
And if a use case does not cleanly fit either model, that is often a sign the product architecture deserves a rethink.
FAQ
What is CHIPS in web development?
CHIPS stands for Cookies Having Independent Partitioned State. It allows a cookie to be scoped not just to the cookie-setting origin, but also to the top-level site where it was set, which helps preserve useful embedded state without enabling broad cross-site tracking.
When should I use partitioned cookies?
Use partitioned cookies when an embedded service, widget, or component needs state that should remain specific to the site where the user is interacting with it, such as chat, maps, payments, or certain CMS and CDN scenarios.
What are Related Website Sets?
Related Website Sets are a browser mechanism that lets an organization declare relationships among domains it controls, so the browser can allow limited cross-site data access for specific use cases like shared sign-in or continuity across related sites.
Is CHIPS enough for single sign-on across multiple domains?
Usually not. CHIPS is designed for partitioned, site-scoped state. If you need limited continuity across multiple company-owned domains, you may need Related Website Sets together with the Storage Access API, depending on your flow.
Are partitioned cookies broadly supported now?
Support improved significantly by late 2025, and MDN lists partitioned cookies as Baseline newly available since December 2025. Teams still need to check target-browser requirements, but this is no longer a purely experimental feature for many products.