Cross-Domain Consent Sharing: How to Sync Cookie Consent Across Multiple Websites

One Visitor, Many Domains, One Decision

Plenty of organizations operate more than one website. A media company runs a dozen titles; a retailer keeps separate domains for separate brands; a SaaS business splits its marketing site, app, and help center across different hosts. From the visitor's point of view it is all the same company — so being asked to accept or reject cookies on every single domain feels broken. From your point of view, it is also a compliance liability: if the same person opts out on one site and opts in on another because they were asked twice, your records contradict each other.

Cross-domain consent sharing solves this by carrying a visitor's consent decision from one of your domains to the next, so they decide once and the choice follows them. But it is not as simple as flipping a switch, and it is not always legally permitted. This guide covers both halves: the technical reason cookies cannot do this on their own, and the legal conditions that determine when sharing is allowed at all. If you serve a global audience, this pairs closely with the idea of adapting one banner per region — and with the consent records discussed in Consent Logging & Audit Requirements.

Why Cookies Alone Cannot Share Consent

The core technical obstacle is that cookies are scoped to a domain. A cookie set on brand-a.com is, by design, completely invisible to brand-b.com. This is a deliberate browser security boundary called the same-origin policy, and it is the same mechanism that stops one site from reading another's session. So a consent cookie stored on your first domain simply does not exist as far as your second domain is concerned. Browsers have also spent years tightening third-party cookie behavior, which closes the old workarounds that relied on a shared third-party cookie acting as a cross-site identifier.

There is one important exception: subdomains of the same registrable domain. A consent cookie set with a domain attribute of .example.com is readable by app.example.com, shop.example.com, and help.example.com alike. So if your "multiple sites" are really subdomains of one parent domain, consent sharing is straightforward and built into how cookies work. The hard problem is sharing across genuinely different registrable domains, where the same-origin boundary blocks you.

How Cross-Domain Sharing Is Actually Implemented

Because browsers block the simple approach, sharing consent across distinct domains relies on one of a few deliberate patterns:

• A central consent service — a shared backend (or a consent management platform) that stores the decision against a token and lets each domain query or write to it. The user's choice lives in one place; each site reads from it.
• Redirect or postMessage handoff — when a visitor crosses from one of your domains to another, the consent state is passed along, either through a short redirect that carries a token or through a hidden iframe using the browser's postMessage channel to relay the stored decision.
• Identity-tied consent — for logged-in users, the cleanest option: store the consent decision against the user's account, so it applies everywhere they sign in regardless of domain.

Each pattern has trade-offs in complexity and privacy. The redirect and iframe approaches must be built carefully so they do not themselves become a covert cross-site tracking mechanism — which would defeat the privacy purpose and create a new compliance problem. A consent management platform that offers cross-domain sharing handles the token plumbing and the security boundaries for you, which is why most teams do not build this by hand. Whatever the mechanism, the gating logic that suppresses tags is the same on each domain; see How to Block Scripts Until Cookie Consent.

The Legal Condition: Same Controller, Clear Transparency

This is where most discussions of cross-domain consent skip ahead too fast. You cannot share consent across domains just because it is technically convenient. The decisive question under GDPR is who the data controller is. Consent is given to a specific controller for specific purposes. If two domains are operated by the same legal entity (or a clearly disclosed group of joint controllers), sharing a consent decision between them can be legitimate — the user consented to that controller, and the controller operates both sites.

If the domains belong to different legal entities, sharing consent becomes far more fraught. A user who consented to Company A did not thereby consent to Company B, even if the two are commercially linked. Quietly porting consent across separate controllers risks turning a valid consent into an invalid one. The safe path requires two things: the relationship between the domains must be transparently disclosed to the user at the point of consent, and the purposes consented to must genuinely match across the domains. The standard for valid consent — specific, informed, freely given — does not relax just because the sites share an owner. For the foundations, see What Is GDPR?.

Keeping Withdrawals in Sync

Sharing the initial "accept" is the easy part. The harder discipline is keeping withdrawals synchronized. If a user opts out on one domain but your sharing only ever propagates opt-ins, you have built a system that respects consent but ignores its revocation — a serious problem, because GDPR requires withdrawal to be as easy as granting. A correctly designed cross-domain system treats the shared consent state as a single source of truth that flows both ways: when the user changes their mind anywhere, the new state propagates everywhere on their next visit.

This is exactly why a central consent store tends to beat ad-hoc redirect tricks for anything beyond two sites. With a single authoritative record, an opt-out is just an update to that record, and every domain reads the current value. With scattered per-domain cookies stitched together by handoffs, it is easy for one domain to keep firing tags long after the user opted out elsewhere — the precise failure mode regulators look for.

Get the Architecture Right Once

Cross-domain consent sharing is one of those features that looks like a UX nicety but is really a compliance architecture decision. Built correctly — a single authoritative consent record, transparent disclosure, two-way withdrawal sync, and a clean controller relationship — it delivers a seamless experience that is also defensible. Built carelessly, it becomes either a broken experience where users get asked repeatedly, or worse, a covert tracking layer that converts a privacy feature into a violation.

The teams that get this right decide early whether their estate is subdomains or separate domains, confirm the controller relationship with their legal team, and let a consent management platform handle the token plumbing rather than reinventing it. For the broader context of how consent fits into your stack, read What Is a CMP?, and for the legal definitions of controllers and consent, consult the GDPR text and EDPB guidance.