Cross-domain and cross-site cookies explained
A cross-domain cookie is not a cookie that unrelated domains can read directly. Browsers scope a cookie to the host that set it or to that host’s parent domain and subdomains. If two organizations use different registrable domains, such as example.com and example.net, they need an explicit handoff, server-side integration or consent platform to share a state between them.
People often use cross-domain and cross-site cookies as if they mean the same thing. They overlap, but they describe different browser relationships. The sections below explain the difference, what current browsers allow and how organizations can keep consent choices aligned across trusted websites.
This article provides general information about web cookies and consent technology. It is not legal advice.
The short answer
| Question | Answer |
| Can a cookie be shared directly between unrelated domains? | No. A server cannot set a cookie for a different unrelated domain, and JavaScript cannot read another domain’s cookie. |
| Can subdomains share a cookie? | Often, yes. A cookie set for a parent domain can be sent to its subdomains, subject to browser and cookie-attribute rules. |
| What does cross-site mean? | Cross-site describes a request or resource involving different sites. SameSite controls when a cookie is sent with those requests. |
| Can consent travel across different domains? | Yes, when a trusted integration synchronizes the consent state through first-party, server-side, redirect or platform mechanisms. |
So let’s explore what they are and how your organization can use them to optimize the user experience…
- Understanding the types of cookies
- Diving deeper: What is a cross-domain cookie?
- The benefits of cross-domain cookies
- Considerations and security measures
Understanding the types of cookies
Before delving into cross-domain cookies, let’s refresh our understanding of cookies. Cookies are small text files that are stored on a user’s device by their web browser. They serve as a means to store various types of data related to a user’s interaction with a website.
This data can include user preferences, session information, authentication tokens, and more. Cookies play a crucial role in personalizing user experiences, maintaining user sessions, and enabling features like shopping carts in online stores.
Key types of cookies:
Session cookies: Session cookies are temporary cookies that are stored in a user’s browser for the duration of their browsing session. They are typically deleted once the user closes the browser. These cookies are often used to store temporary information such as user preferences, items in a shopping cart, or data required to maintain a user’s login session.
Persistent cookies: Unlike session cookies, persistent cookies remain on the user’s device even after they close the browser. These cookies have an expiration date set by the website, which determines how long they will remain on the user’s device. Persistent cookies are used for purposes like remembering login credentials, tracking user preferences across sessions, and providing personalized experiences.
Secure cookies: Secure cookies are designed to be transmitted only over encrypted (HTTPS) connections. They help ensure that sensitive data stored in cookies, such as login credentials or authentication tokens, is transmitted securely between the user’s browser and the website’s server.
HttpOnly cookies: HttpOnly cookies can only be accessed by the server and are not accessible via client-side scripts like JavaScript. This adds a layer of security against cross-site scripting (XSS) attacks, where malicious scripts try to access sensitive data stored in cookies.
Same-site cookies: Same-Site cookies specify whether cookies should be sent with cross-origin requests under three options (strict, lax and none).
Third-party cookies: Third-party cookies are set by domains other than the one the user is currently visiting. They are often used by advertisers and tracking services to monitor user behavior across different websites. Third-party cookies have raised privacy concerns, leading to changes in browser policies that limit their usage.
Cross-domain cookies: Cross-domain cookies can be shared and accessed across multiple domains. They are often used for purposes like Single Sign-On (SSO) and data sharing between related websites.
What is a cross-domain cookie?
In everyday marketing language, a cross-domain cookie usually means a cookie-related journey that involves more than one domain. In browser terms, however, cookies remain scoped. A response from app.example.com may set a cookie for app.example.com or, where permitted, example.com. It cannot set Domain=example.net. The second domain must receive state through its own request and its own cookie or storage.
That distinction matters for security, privacy and implementation planning. A cross-domain customer journey can be joined without making one domain read another domain’s cookie. The join might use a short-lived signed token in a top-level redirect, a back-channel API, an authenticated identity flow or a consent service that records and returns the relevant state.
Cross-site and cross-domain cookies are not the same
| Term | Meaning | Cookie implication |
| Same-origin | Same scheme, host and port. | Web APIs such as document.cookie and local storage are restricted to the origin. |
| Same-site | Usually the same registrable domain and scheme under schemeful-site rules. | SameSite controls whether cookies are sent with requests from the same site or a different site. |
| Cross-site | A request, navigation or embedded resource involving different sites. | Third-party cookie blocking, partitioning and SameSite rules may limit cookie access. |
| Cross-domain | Commonly used for different registrable domains, such as example.com and example.net. | A cookie cannot be scoped across the two domains. Use an explicit state handoff instead. |
Subdomains can be cross-origin while still being same-site. For example, shop.example.com and account.example.com do not share an origin, but they may be treated as the same site. This is why the words origin, site and domain should be used precisely when documenting a cookie implementation.
How cookies are scoped
Domain. If omitted, the cookie is host-only. If set to a permitted parent domain, the cookie can be sent to that domain and its subdomains. The attribute cannot name an unrelated domain or a public suffix.
Path. Limits the request paths that receive the cookie. It does not make a cookie safe from scripts or replace access-control protections.
SameSite. Strict and Lax restrict cross-site sending. None permits cross-site sending only when Secure is also present, and browser privacy controls can still block the request.
Secure and HttpOnly. Secure limits transmission to HTTPS. HttpOnly prevents client-side JavaScript from reading the cookie, which helps reduce exposure in an XSS incident.
Partitioned. Partitioned storage keeps a third-party cookie in a separate jar for each top-level site. It is not a way to share one cookie across unrelated sites.
Set-Cookie: consent_state=accepted; Domain=example.com; Path=/; Secure; HttpOnly; SameSite=Lax
The example can cover example.com and its subdomains when the response comes from a permitted host. It does not grant access to example.net. Always test the rendered Set-Cookie response, not only a CMS field or JavaScript snippet.
How can websites work across different domains?
Top-level redirect handoff
The user is sent to the second domain in a top-level navigation with a short-lived, signed state value. The destination validates it, creates its own first-party cookie and removes the value from the address bar.
Server-side or API exchange
A trusted backend exchanges an authenticated session or one-time code and returns only the minimum state the destination needs. This avoids asking a browser to read another domain’s cookie.
Federated identity or SSO
An identity provider can authenticate the user across relying parties. Each domain still maintains its own session and cookie, even though the user experiences one sign-in.
Cross-domain consent service
A consent platform can store a consent record centrally and provide each approved domain with the current state through first-party or API-based mechanisms. The record should include purpose, scope, timestamp and version information.
Do not describe CORS as cookie sharing. CORS controls whether a browser allows a requesting origin to read a response. It does not let JavaScript read another domain’s cookie, and credentialed requests still depend on cookie attributes and browser policy.
Browser privacy changes in 2026
Browser behavior is not uniform, so a cross-domain design that works in one test browser may fail in another. Safari’s Intelligent Tracking Prevention blocks third-party cookies by default and can restrict other script-writeable storage. Chrome continues to expose third-party cookie controls through browser settings, and availability can depend on user choice, context, mode and rollout. Treat third-party cookies as an unreliable dependency rather than a universal transport for consent or identity.
Build and test the user journey in Safari, Chrome and other browsers that matter to your audience. Test normal browsing, private browsing, blocked third-party cookies, redirects, embedded frames, consent withdrawal and a user who starts on one domain and finishes on another.
Cross-domain consent is different from cross-domain cookies
Cross-domain consent means applying a person’s consent choice across approved websites or brands. It does not require one domain to read another domain’s cookie. A consent management system can capture the choice once, resolve the permitted scope and synchronize the state through first-party mechanisms, secure identifiers, redirects or APIs.
For enterprise estates, cross-domain consent management can reduce repeated banners while keeping consent records and enforcement aligned across connected domains. The implementation still needs clear notices, valid choice, purpose scope and an auditable change history.
Use cases, security and privacy checks
- Single sign-on. Use an identity flow or one-time exchange so each domain creates its own session. Do not put a long-lived access token in a URL or attempt to copy a session cookie between domains.
- Consent synchronization. Share only the consent state and scope that the approved domains need. Record when it was collected, which notice applied and how withdrawal propagates.
- Analytics and measurement. Confirm the lawful basis, purpose and retention before joining journeys across domains. Browser restrictions can reduce observability, so do not treat missing identifiers as proof that a person did not visit.
- Personalization. Prefer declared preferences or authenticated state over silent cross-site tracking. Give people a clear way to review and change the choices that shape their experience.
- Security. Use HTTPS, short-lived signed values, replay protection, strict redirect allowlists and least-privilege APIs. Keep sensitive authentication data out of client-readable cookies where possible.
Related cookie and storage concepts
Cookies are only one browser storage mechanism. See the guide to session cookies for temporary cookie behavior and the guide to local storage, session storage and cookies for a practical comparison of browser storage options.
Considerations and security measures
While cross-domain cookies offer several advantages, they also come with considerations and potential security concerns. As with anything to do with user data, you need to take care and do your due diligence to maintain trust and ensure compliance with any relevant legislation.
Privacy implications: The sharing of user data across domains raises privacy concerns. Users might not be comfortable with their information being shared between websites without clear consent and understanding of how their data will be used.
Security risks: If not implemented carefully, cross-domain cookies could be exploited by malicious actors to gain unauthorized access to user data. Proper encryption and authentication mechanisms are crucial to mitigate these risks.
User consent and control: Websites employing cross-domain cookies must prioritize transparency and user control. Providing clear information about data sharing practices and giving users the ability to opt in or out is essential.
Cross-domain cookies are a powerful tool that enables enhanced collaboration and a more seamless online experience for users. They enable single sign-on, facilitate data sharing for personalization, and allow for better tracking of user journeys across multiple websites.
However, their implementation requires careful consideration of privacy and security concerns. Working with a consent management platform that can implement these for you without risking non-compliance is essential.
As we see the depreciation of third-party cookies and user-experience expectations continue to evolve, cross-domain cookies will likely remain a central element in the pursuit of creating unified, user-centric online experiences.
How Syrenis supports cross-domain consent
Syrenis helps organizations capture consent once and apply it across connected domains without relying on one domain reading another domain’s cookie. The approach is designed for consistent consent experiences, centralized oversight and auditable records across complex digital estates.
For the wider implementation context, read about cookie management and cross-domain consent management.
Frequently asked questions
What is a cross-domain cookie?
The phrase usually describes a cookie-related journey across more than one domain. A browser cookie is still scoped to the host that set it or to an allowed parent domain and its subdomains. Unrelated domains need an explicit handoff or integration.
Can cookies be shared between different domains?
Not directly. A server cannot set a cookie for an unrelated domain, and JavaScript cannot read another domain’s cookie. Use a redirect or token handoff, server-side exchange, identity provider or consent platform instead.
What is the difference between cross-site and cross-domain cookies?
Cross-site describes requests or resources involving different sites. Cross-domain is commonly used for different registrable domains. Subdomains can be cross-origin while still being same-site, so the terms should not be treated as interchangeable.
Do cross-domain cookies work in Safari and Chrome?
There is no single browser guarantee. Safari blocks third-party cookies by default through Intelligent Tracking Prevention. Chrome availability depends on user settings, context and mode. Test the complete journey with third-party cookies blocked.
Can consent be shared across multiple domains?
Yes, when approved domains use a consent service or explicit first-party, server-side, redirect or API-based synchronization. The implementation should define scope, record the decision and support updates or withdrawal.
Is CORS the same as cross-domain cookie sharing?
No. CORS governs whether a browser allows one origin to read a response. It does not allow JavaScript to read another domain’s cookies, and credentialed requests remain subject to cookie attributes and browser policy.