Debugging Cross-Domain Consent Cookie Drops in Safari and iOS

When a consent choice appears to disappear between domains in Safari, the most useful question is not “How do I make Safari keep the cookie?” It is: where, exactly, did the consent state stop being available?

As of August 2026, Safari 26.6 is the current stable Safari release. Safari 27 is still in beta. That version distinction matters because WebKit’s storage behaviour continues to change: for example, CHIPS support was introduced, temporarily removed, and then restored in Safari 26.2.

What Does “Consent Cookie Dropped” Actually Mean?

A missing consent choice can describe several different failures. The value may never have been written, Safari may have rejected it, the browser may have stored it but withheld it from a request, or JavaScript may not be able to read it from the current context. The CMP may also rely on local storage or another browser-storage mechanism in addition to its normal consent cookie.

These cases are not interchangeable.

A useful debugging model separates three questions:

1. Was the state stored? Check the cookie or other storage immediately after consent.
2. Is the state sent where expected? Inspect the relevant network request and its Cookie header.
3. Can the current page access it? Check document.cookie, local storage and the browsing context.

An HttpOnly cookie, for example, can exist and be sent to a server while remaining invisible to document.cookie. Likewise, finding a cookie in the browser’s storage view does not prove that an unrelated website, cross-site iframe or cross-site request can use it.

Terminology matters here. An origin includes the scheme, host and port. A site is generally based on the registrable domain; for SameSite cookie rules, the scheme is also considered. This means https://www.example.com and https://shop.example.com are different origins but same-site, while https://example.com and https://example-shop.com are cross-site.

Local Storage is normally origin-scoped JavaScript-accessible storage. Session Storage is also origin-scoped but tied more closely to a browsing session. Neither should be treated as another name for a cookie.

WebKit also treats third-party storage differently from normal First-party storage. Its current Tracking Prevention documentation states that third-party local storage and IndexedDB are partitioned by the First-party website and made ephemeral.

That is why a consent cookie appearing normally on Domain A does not automatically mean that a separate cross-domain consent mechanism will be able to recover the same state on Domain B.

Cross-Domain Consent Is Not the Same as Subdomain Consent

Many apparent Safari cross-domain cookie problems are really cookie-scope problems.

Consider:

www.example.com
shop.example.com
account.example.com

These are subdomains beneath example.com. An appropriately configured domain cookie can potentially be available to these hosts.

Now compare:

example.com
example-shop.com

These are separate registrable domains. A normal cookie created by example.com cannot simply declare example-shop.com as its Domain.

Setting:

Domain=.example.com

does not change that. The leading dot is effectively ignored by modern cookie handling; the important part is that the declared domain must be the current domain or an appropriate parent domain.

This distinction should be established before investigating ITP. If an implementation expects an ordinary first-party cookie to move directly between unrelated registrable domains, no Safari-specific setting can make that cookie scope valid.

CookieScript also treats subdomain consent separately from cross-domain consent. With Remember Consent for Subdomains, the parent domain should be entered without www or a protocol, and the same banner should be installed on the participating subdomains. CookieScript’s current instructions use example.com as the parent-domain pattern, not a child such as shop.example.com.

Subdomain sharing also makes most sense when the participating sites use the same or compatible cookies and tracking technologies. If different subdomains require materially different consent choices, separate configurations may be more appropriate.

Check Where the Consent State Fails

Once the domain relationship is clear, debug the state in sequence rather than changing cookie attributes at random.

Start on Domain A before consent. Record the existing cookies and local storage values. Make a consent choice, then inspect them again.

For the consent cookie itself, check:

• Name: make sure you are looking at the actual CMP consent cookie rather than an analytics or application cookie.
• Domain: determine whether it is host-only or intentionally scoped to a parent domain.
• Path: confirm that the request URL falls within the expected cookie path.
• SameSite: record the actual value.
• Secure: check both the attribute and whether the production page uses HTTPS.
• HttpOnly: remember that this prevents JavaScript access but not normal HTTP transmission.
• Expires / Max-Age: check whether the application itself is setting an unexpectedly short lifetime.
• Partitioned: determine whether you are looking at partitioned rather than unpartitioned state.
• Setter: establish whether JavaScript or an HTTP Set-Cookie response created the cookie.

Then reload Domain A.

If the preference disappears on the same site after an ordinary reload, the cross-domain mechanism is not yet the problem. Diagnose that first-party persistence failure before continuing.

If the state survives, inspect the Network panel and browser cookie storage. The response that creates a server-set cookie should show Set-Cookie. A later request that is eligible to carry it should show the corresponding Cookie request header.

“No Cookie header” does not automatically mean “the CMP failed to save consent”. The browser may have saved the cookie correctly but excluded it from that request because of its scope, SameSite rules, Secure requirements or cross-site Privacy Policy.

The reverse can also happen: the cookie may be sent correctly while JavaScript cannot read it because it is HttpOnly.

Do not stop at cookies. CookieScript’s current cross-domain consent guidance says that a cross-domain consent-sharing local-storage item participates in the feature and is classified in the Preferences category. Finding the normal consent cookie is therefore not proof that the storage needed for cross-domain synchronisation is available.

How Safari Treats Cross-Site Cookies and Storage

This is the point at which ITP becomes relevant.

WebKit’s Tracking Prevention policy blocks ordinary unpartitioned third-party cookie access by default. Since Safari 26.2, third-party content can separately opt in to partitioned cookies through CHIPS, which isolates those cookies by top-level site. It also partitions third-party Local Storage and IndexedDB by the first-party website. In practical terms, storage that is readily available while a service is first-party may not be exposed in the same way when that service appears as third-party content elsewhere.

This is also why SameSite=None; Secure should not be treated as an ITP workaround.

SameSite answers a cookie-semantics question: is the cookie eligible to accompany this request?

SameSite=Strict is the most restrictive. Lax permits a narrower range of cross-site navigation cases. None allows cross-site eligibility and must be combined with Secure.

For example:

Set-Cookie: preference=value; SameSite=None; Secure

That can make a cookie syntactically eligible for cross-site transmission. It does not force WebKit to expose third-party cookie storage that its privacy model blocks.

CookieScript’s dashboard provides a SameSite setting for its consent cookie, with Lax, Strict, None and Default options. The correct value should reflect the required cookie behaviour rather than an attempt to bypass browser tracking protection.

The familiar “Safari deletes cookies after seven days” explanation also needs qualification. Current WebKit documentation describes a seven-day cap after no user interaction for JavaScript-created cookies and other script-writeable storage. Separate protections include a 24-hour cap for JavaScript-created cookies following detected link-decoration tracking and seven-day limits for response cookies in defined third-party CNAME or IP-cloaking cases.

Those restrictions should not be generalised to every Safari cookie.

Redirect behaviour matters for the same reason. WebKit detects patterns associated with cross-site redirects, bounce tracking and link decoration. Passing durable identifiers through URLs purely to reconstruct storage that Safari has blocked is not an appropriate production solution.

A consent preference should remain a record of what the visitor chose, not become a durable mechanism for recreating cross-site identity.

CHIPS and the Storage Access API Solve Different Problems

Two newer browser technologies often appear in discussions about Safari cookie problems: CHIPS — Cookies Having Independent Partitioned State — and the Storage Access API. Neither should be described as a generic fix for cross-domain consent.

CHIPS

CHIPS — Cookies Having Independent Partitioned State — lets third-party content opt in to a partitioned cookie that is partitioned by the top-level site.

Safari first shipped CHIPS in 18.4, temporarily removed it in 18.5, and restored it in Safari 26.2.

In current Safari, a partitioned cookie uses:

Set-Cookie: preference=value; SameSite=None; Secure; Partitioned

WebKit keys each partition to the top-level site. If service.example is embedded on Site A, its partitioned cookie is available in Site A’s partition. When the same service appears under unrelated Site B, it receives a different partition.

That is useful for third-party functionality without unrestricted cross-site state, but it also explains why CHIPS does not create one globally shared consent cookie across unrelated websites.

Storage Access API

The Storage Access API addresses a different requirement: embedded cross-site content that needs access to its own unpartitioned storage.

An iframe can determine whether it has storage access and, where browser requirements are satisfied, request it. The initial request commonly involves user activation and browsers may impose prior first-party interaction or other permission requirements. Sandboxed iframes also require the relevant sandbox permissions.

WebKit itself points developers towards the Storage Access API when unpartitioned third-party cookie access is genuinely required.

That architecture is not the same as a visitor leaving Domain A, navigating to Domain B as a new top-level site, and expecting a CMP preference to follow.

CookieScript does not document the Storage Access API as a workaround for its Safari cross-domain consent limitation. It should therefore not be presented as one.

How CookieScript Cross-Domain Consent Works

CookieScript supports cross-domain cookie consent sharing for groups of websites, including multiple top-level domains. Participating sites are configured through a Cross-domain consent group in the dashboard. The current feature documentation also specifies that the project must use the Plus plan.

The current configuration also provides two ways to exclude a domain from cross-domain consent sharing in the documented scenarios. Direct installations can use the documented data-cs-ignore-read-crossdomain attribute for the specific exclusion scenario described in the Help Centre. The dashboard also provides an Ignore checkbox, which works with both direct installation and Google Tag Manager. If Ignore is checked for a domain, that domain will not participate in cross-domain consent sharing.

CookieScript’s current guidance says websites in the group should use the same cookies or other tracking technologies. Preferences consent also matters because CookieScript classifies the cross-domain local-storage item under Preferences.

The most important Safari-specific fact is the limitation itself.

CookieScript’s current documentation states that cross-domain Cookie Consent sharing does not work in Safari because Safari does not share the required third-party local storage across browser tabs.

That limitation is not a cue to keep changing SameSite, add partitioned cookies or reproduce the consent identity through another tracking technique.

In practice, if Safari prevents the documented sharing mechanism from recovering the preference, Domain B may need to show its own banner and collect consent independently.

That is not necessarily undesirable. If the domains have different cookies, vendors, purposes or consent categories, carrying exactly the same preference across both sites may not even represent the correct consent context.

A Safari Cross-Domain Consent Debugging Workflow

A reproducible test usually reveals more than experimenting with individual cookie flags.

1. Classify the sites. Are they subdomains of one registrable domain or genuinely separate domains?
2. Locate the consent state. Identify the normal consent cookie, relevant Local Storage and any other state used by the implementation.
3. Confirm Domain A works alone. Give consent, reload and verify that the preference survives.
4. Inspect the write. Look for Set-Cookie, browser storage changes and relevant console warnings.
5. Inspect the next request. Check whether the expected Cookie header is present.
6. Test subdomains separately. Verify parent-domain configuration rather than assuming a subdomain issue is the same as a cross-domain issue.
7. Navigate to Domain B. Inspect its state before the banner or application changes anything.
8. Identify third-party contexts. Record any iframes, embedded requests or redirects involved in synchronisation.
9. Check for blocked or partitioned storage. Decide whether the browser is preventing access rather than assuming the value was deleted.
10. Verify the CookieScript configuration. Check the cross-domain group, Ignore settings, banner setup and Preferences consent.
11. Compare the result with documented browser support. If the final failure is Safari’s documented product limitation, determine whether Domain B needs to collect consent independently.

Test this flow in more than one context. At minimum, compare current Safari on macOS and Safari on current iOS, normal navigation and direct entry to Domain B, reloads, Back/Forward navigation, new tabs, Private Browsing, and relevant content-blocker states.

Also test the actual HTTPS production environment. Local development and simplified staging environments can hide Secure, Domain and redirect problems.

For each reproduction, record the exact Safari and operating-system version, top-level URL, any iframe URL, cookie attributes, Local Storage values, request and response headers, whether Private Browsing was enabled and whether a content blocker was active.

Private Browsing and content blockers deserve separate test cases. WebKit documents Safari Private Browsing as ephemeral and isolates tabs into separate ephemeral sessions. A result that occurs only there is not automatically the same problem as ordinary ITP behaviour.

Likewise, if disabling a content blocker changes the outcome, investigate the blocker independently.

Temporarily comparing Safari with “Prevent Cross-Site Tracking” changed can sometimes help isolate which browser layer is responsible. This is a diagnostic comparison, not a production solution. The deployed implementation should work within Safari’s normal protections.

Common Cross-Domain Consent Debugging Mistakes

• Cross-domain vs subdomain confusion: expecting unrelated registrable domains to behave like shop.example.com and www.example.com.
• Cookie existence vs cookie access: assuming a stored cookie must be readable or sent in every context.
• SameSite as an ITP workaround: treating SameSite=None; Secure as a way around ITP.
• The universal seven-day rule: treating conditional script-storage restrictions as the lifetime of every Safari cookie.
• Outdated Safari assumptions: relying on old ITP or CHIPS guidance without checking the shipping WebKit behaviour.
• CHIPS misunderstanding: treating partitioned cookies as shared cross-site state.
• Storage Access API misuse: treating it as a general consent-sync API.
• Cookie-only debugging: ignoring Local Storage or other state used by the CMP.
• Incorrect parent domain: configuring a child host instead of the actual parent domain for subdomain consent.
• Browser limitation mistaken for banner failure: blaming CMP code when the browser deliberately prevents access.
• Privacy bypass attempts: rebuilding blocked cross-site identity instead of designing the appropriate fallback.
• One-browser testing: assuming Chrome success or desktop Safari success establishes iPhone behaviour.

Managing Cross-Domain Consent With CookieScript

CookieScript handles the consent side of this architecture. Safari and WebKit determine whether cookies and other browser storage are available in a particular first-party, cross-site or partitioned context, while CookieScript handles the Cookie Banner, consent configuration and the recording and application of consent choices.

CookieScript is a Consent Management Platform (CMP) that Google includes among the CMP partners available for Consent Mode setup. It is also a Google-certified CMP.

Depending on your plan and setup, relevant tools include:

• Cross-domain cookie consent sharing for grouping websites that use the same cookies or other tracking technologies and need to recognise the same Cookie Consent choice across separate domains where the browser supports the required storage mechanism.
• Remember Consent for Subdomains for sharing consent between suitable subdomains under the same parent domain. This is different from cross-domain cookie consent between separate registrable domains.
• Cookie Banner for presenting consent choices and configuring the banner shown to visitors on each participating website.
• Cookie Scanner for identifying cookies and related tracking technologies across websites before deciding whether they should use the same cross-domain or subdomain consent configuration.
• User consents recording for collecting and retaining records of visitors’ cookie choices separately from the browser-side consent storage being investigated.
• Third-party cookie blocking for controlling third-party technologies according to the selected consent setup.
• Geo targeting for applying different Cookie Banner behaviour based on visitor location where participating domains require regional consent configurations.
• Consent events for website, application or GTM logic that needs to respond to visitor choices, consent categories and CookieScript initialisation.
• SameSite consent-cookie configuration for selecting the appropriate SameSite behaviour of the CookieScript consent cookie.

Additional tools for automation, reporting and wider consent management include:

• 42 languages for multilingual Cookie Banners and cookie information across websites serving different markets.
• Automatic monthly scans to rescan participating websites as their cookies and tracking technologies change.
• Automatic script blocking for controlling applicable third-party scripts before the relevant consent is available.
• Advanced reporting for analysing cookie banner interactions, acceptance, rejection and category preferences.
• Google Consent Mode v2 for providing supported consent states to Google tags. Consent Mode communicates consent to Google services; it does not itself synchronise a preference between domains.
• Google Tag Manager integration for setups where CookieScript and consent-aware tags are deployed through GTM.
• Cookie Banner sharing for sharing banner access between CookieScript accounts where supported by the selected plan. cookie banner sharing is a different feature from cross-domain consent sharing and does not itself transfer a visitor’s consent state between websites.
• IAB TCF 2.3 integration for advertising environments that use the IAB Europe Transparency & Consent Framework.
• Privacy Policy Generator for creating a Privacy Policy for a website or business.

A 14-day free trial of the Plus plan is also available without requiring a credit card.

Conclusion

When a cookie banner reappears on another domain in Safari, “the consent cookie was dropped” is only a symptom. The useful distinction is whether the failure comes from cookie scope or configuration, or from Safari’s documented limits on the CookieScript cross-domain mechanism. Following the diagnostic sequence above separates those cases without trying to work around the browser’s privacy protections.

Frequently Asked Questions

Why does cross-domain consent work in Chrome but not Safari?

Browser storage policies differ. WebKit blocks unpartitioned third-party cookies by default and partitions third-party Local Storage, while CookieScript currently documents Safari as unsupported for its cross-domain consent mechanism. A successful Chrome test therefore does not prove that the same storage architecture is available in Safari.

Can SameSite=None; Secure fix Safari cross-domain consent?

No. SameSite=None; Secure can make a cookie eligible for cross-site transmission, but those attributes do not disable ITP or force Safari to provide third-party storage access. They should be used when required by the cookie’s intended request behaviour, not as an ITP workaround.

Can I share one normal cookie between two different top-level domains?

Not with ordinary cookie Domain scope. A cookie belonging to example.com cannot simply declare an unrelated domain such as example-shop.com. Separate top-level sites need another cross-domain consent mechanism.

What is the difference between subdomain consent and cross-domain consent?

Subdomains such as shop.example.com and account.example.com belong beneath the same registrable domain and can potentially use parent-domain cookie scope. Separate registrable domains cannot. CookieScript therefore provides separate subdomain consent and cross-domain consent configurations.

Does Safari’s Storage Access API fix CookieScript cross-domain consent?

CookieScript does not currently document it as a solution for that feature. The Storage Access API primarily exists for embedded cross-site content that needs access to its own unpartitioned storage, which is a different architecture from synchronising consent between two top-level websites.

Can CHIPS share consent across multiple websites?

Not as one global consent cookie. Safari partitions CHIPS cookies by site, so the same third-party service embedded beneath two unrelated top-level sites receives separate partitions.

Why does the cookie banner appear again on an iPhone?

First check whether the second website is a subdomain or another registrable domain and whether consent survives a reload on the first site. For Safari on iOS, CookieScript’s current cross-domain consent documentation states that its cross-domain consent-sharing mechanism does not work because of the required third-party storage behaviour, so another consent request on the second site may be expected.

How do I debug a consent cookie that appears to be missing in Safari?

Start with the Network panel and browser storage together. Check whether the value was created, whether a response contained Set-Cookie, whether a later request included Cookie, and whether JavaScript should be able to read the value. Then inspect Domain, Path, SameSite, Secure, HttpOnly and expiry, partitioning and Local Storage before investigating the CMP’s cross-domain configuration.