Safari ITP and Cookie Consent: Why Visitors Keep Seeing Your Banner

Visitors on Safari keep seeing your cookie banner because Intelligent Tracking Prevention (ITP) deletes every cookie your site's JavaScript has written, together with its local storage, once a visitor has used Safari for seven days without clicking, tapping or typing on your site. A consent management platform (CMP) stores the visitor's choice in exactly that kind of cookie, so the choice vanishes and the banner asks again.

Key takeaways:

• Safari's rule is seven days of browser use without user interaction on your site, not seven calendar days, and scrolling doesn't count as interaction.

• Moving the consent choice to local storage changes nothing: ITP deletes local storage, session storage and IndexedDB on the same schedule.

• Cookies set by an HTTP response from your own host keep their full expiry; cookies from a subdomain that resolves to third-party infrastructure are capped at seven days.

• The ICO and the CNIL both treat six months as a sensible period for remembering a choice, and both object to repeated prompting, particularly after a refusal.

• Your consent log, not the browser cookie, is your proof of consent under Article 7(1) GDPR, so ITP deleting the cookie doesn't erase your compliance record.

What Does Safari ITP Actually Do to Your Consent Cookie?

ITP keeps a per-site counter of the days Safari has been used without any user interaction on that site. When the counter reaches seven, Safari deletes the site's script-writable storage: cookies created with document.cookie, localStorage, sessionStorage, IndexedDB and service worker registrations. Cookies delivered by a first-party HTTP response are not part of that purge.

The rule has changed shape three times. In February 2019, ITP 2.1 capped the expiry of any cookie written through document.cookie at seven days. In March 2020, WebKit extended the limit to every other form of script-writable storage, phrased as deletion after seven days of Safari use without user interaction on the site. By late 2022, WebKit had stopped rewriting the expiry date of JavaScript cookies and folded them into that deletion rule instead. Apple documents the current behaviour in its Tracking Prevention in WebKit reference.

That last change matters for debugging. Web Inspector may show a twelve-month expiry on the consent cookie. Safari will still delete it on schedule.

User interaction means a click, a tap or keyboard input on your site in a first-party context. Scrolling doesn't qualify. Answering the banner does, because the Accept and Reject buttons sit in your page's own DOM, so the counter restarts at zero the moment the visitor chooses. A returning visitor who reads two articles and leaves without clicking anything has not reset it, even if your CMP script rewrote the consent cookie on both page loads.

Days of Safari use are not calendar days. Someone who opens Safari twice a month can hold your consent cookie for the better part of a year. Someone who uses Safari every day and skips your site for eight days loses it.

Campaign traffic has a shorter fuse: if a visitor arrives from a domain that ITP has classified as having cross-site tracking capabilities, and the landing URL carries a query string or fragment such as gclid or fbclid, JavaScript cookies written on that landing page expire after 24 hours. The large ad platforms are routinely classified, so a visitor who clicks a paid ad and accepts your banner may see it again tomorrow.

The cloaking rows need unpacking. Safari's idea of first party is the registrable domain, so consent.example.com is first-party to example.com as far as the Domain Name System (DNS) is concerned. ITP looks one level deeper. If that subdomain resolves through a CNAME to a host outside your domain, or to an IP address on a different network from the one serving your pages, the response counts as third-party cloaking and any cookie it sets is capped at seven days. The exception is when your main host resolves through the same CNAME target, as with some CDNs. Apple added the CNAME check in November 2020 and the IP check in 2023.

As of September 2026, a week after Safari 27 shipped on 14 September, the WebKit reference still describes the seven-day rule in these terms. Neither Safari 26 nor 27 loosened it.

How Many of Your Visitors Are Affected?

Roughly one page view in six worldwide comes from Safari, and the share climbs steeply on mobile and in English-speaking markets. StatCounter's figures for August 2026 put Safari at 15.9% of worldwide page views, 26% on mobile, 28.8% of all traffic in the UK, 29.2% in the United States and 52.9% of United States mobile traffic. Third-party browsers on iPhone and iPad have historically been required to use Apple's WebKit engine, so Chrome or Firefox on an iPhone behaves like Safari here.

The banner is the visible symptom. The rest sit in your reporting.

Every deleted consent cookie turns a returning visitor into a new one. Google Analytics 4 counts a fresh user, your Google Consent Mode v2 tags fall back to their denied defaults until the visitor answers again, and your CMP's dashboard records a second decision from the same person. If Safari shows a higher share of new visitors than Chrome for the same audience, that is the purge showing up as data rather than behaviour. It also feeds consent fatigue, because the people asked most often are your most loyal Safari readers.

Is It ITP, or Something Else? How to Tell

ITP is the most common reason a banner returns for Safari visitors, but it isn't the only one, and each cause has a different fix, so rule out the causes that affect every browser first. A banner that reappears on Chrome too is not an ITP problem.

The consent version case trips up more teams than ITP does. Editing a purpose description or adding a vendor is exactly where regulators expect fresh consent, so a CMP that re-prompts after such a change is doing its job; the trouble starts when a cosmetic edit bumps the version by accident and every visitor is asked again.

Is Re-Prompting Safari Visitors a Compliance Problem?

No regulator has said that a banner returning because a browser deleted a cookie breaks the law. Neither the ICO's nor the CNIL's guidance mentions browser-imposed expiry at all. Both, though, treat how long a choice is remembered as the site's decision, and both set expectations a weekly re-prompt falls well short of.

The Information Commissioner's Office (ICO) says in its guidance on managing consent for storage and access technologies that you shouldn't repeatedly ask people to specify their preferences as a matter of course, particularly where someone has refused, and that it's unfair to keep asking just because you'd like a different answer. It suggests six months as a suitable interval before requesting fresh consent under the Privacy and Electronic Communications Regulations (PECR), and it warns that the default expiry on an off-the-shelf preference cookie (90 days is its example) is a setting you must assess, change if necessary and document.

France's Commission Nationale de l'Informatique et des Libertes (CNIL) takes the same line. Its cookies recommendation, consolidated on 16 January 2026 to add rules on multi-device consent, states that keeping the visitor's choice, whether consent or refusal, for six months is good practice. It also observes that without stored choices a visitor would face a new consent window repeatedly, which could undermine the freedom of that choice. Under the CNIL's cookie guidelines, a refusal has to be remembered just as an acceptance is.

Refusal is where ITP bites hardest. A Safari visitor who clicks Reject and returns after a gap sees the banner again, and again, on a cycle you didn't choose. The effect matches the pattern both regulators call unfair, even though the cause is the browser. Shorten the cycle where you can, and keep Reject as prominent as Accept so a repeat costs one tap. Never treat a missing cookie as permission: no stored choice means nothing that needs consent may load, as set out in what happens after Reject All.

One thing ITP cannot touch is your evidence. Article 7(1) of the General Data Protection Regulation (GDPR) requires you to be able to demonstrate that the visitor consented, and that demonstration lives in your server-side consent log, not in the visitor's browser. Safari deleting the cookie removes the device-side memory of the choice, not your record of it.

How Do Other Browsers Handle Consent Cookies?

Safari is the strictest mainstream browser on script-written first-party cookies, but the others impose limits of their own. Chrome's ceiling is the one to design around: since Chrome 104 in August 2022, any cookie asking for more than 400 days is silently trimmed to 400.

A consent cookie set for twelve months therefore behaves as intended in Chrome, Edge and Firefox, lasts six months in Brave, and lasts as long as the visitor keeps interacting in Safari. The wider rules on cookie duration still apply on top. The consent cookie itself is strictly necessary, though, and needs no consent of its own.

What Keeps a Consent Choice Alive in Safari?

Only two things survive ITP for an anonymous visitor: a cookie set by an HTTP response that Safari treats as first-party, and a record kept on your server. Everything a script writes into the browser is on the seven-day clock; the options below run from cheapest to most involved.

1. Rewrite the cookie on every visit, and accept the limit

Most CMPs already rewrite the consent cookie on each page load with the full intended expiry. That does nothing against Safari's interaction counter, but it costs nothing and keeps the expiry correct in browsers that honour it. On Safari, visitors who return and click something within a week keep their choice; visitors who don't see the banner again. For a news site with daily readers, that covers most of the audience. For a service people visit quarterly, it covers almost nobody.

2. Set the consent cookie from your own server

A Set-Cookie header in a response from the host that serves your pages is the direct route. That can be an endpoint in your application, an edge function on the same host, or a reverse-proxy path such as /consent/ that forwards to your CMP while the browser only ever talks to example.com. Give the cookie Secure, SameSite=Lax and Path=/, and either leave HttpOnly off so the banner script can read it or pair it with a readable JavaScript copy. It is the same principle that makes server-side tagging more durable than browser tags.

3. Use a CMP endpoint on a subdomain, and check how it resolves

Several CMPs, Kukie.io among them, offer HTTP consent cookies: a subdomain such as consent.example.com points at the CMP's cookie server, the banner sends the choice there, and the server replies with a Set-Cookie header carrying a 365-day expiry, with the JavaScript cookie kept as a fallback. Whether Safari honours that expiry depends on how the subdomain resolves. A CNAME to a host outside your domain, or an address on a different network from your main host, puts the response inside ITP's cloaking rule and caps the cookie at seven days, unless your main host resolves through the same CNAME target. Run dig +short against both hosts, compare the chains, and test in Safari before relying on the number. Chrome, Edge and Firefox honour the 365 days regardless.

4. Bind consent to the account for logged-in visitors

For visitors who sign in, store the choice against the account and restore it on login, so the browser cookie becomes a cache rather than the source of truth. The CNIL's December 2025 addition to its recommendation sets the conditions: tell the visitor before they choose that the choice applies on every device where they sign in, propagate refusal and withdrawal exactly as consent, and never let a choice made on a shared device before login overwrite someone else's account. A working cross-device consent setup handles all three.

What doesn't work

• Moving the choice to local storage or IndexedDB. Both sit on the same seven-day purge, and the law treats them like cookies anyway.

• Setting a longer Expires value. Safari no longer rewrites it; it deletes the cookie regardless.

• Hiding the banner without a stored choice. No stored choice means no consent, so every script that needs it stays blocked until the visitor answers again.

• Fingerprinting the device to recognise a returning visitor. That is tracking in its own right, and it needs consent too.

How Do You Test Whether the Fix Works?

Test in Safari itself, on macOS or iOS, rather than in Chrome's device emulation: the behaviour lives in WebKit's network layer, not in how the page renders.

1. Open Web Inspector from the Develop menu, choose Storage, then Cookies. Answer the banner and note the consent cookie's expiry, and whether it appears once (HTTP only) or twice (HTTP plus JavaScript fallback).

2. In the Network tab, find the request your banner sends when the visitor chooses, and check the response for a Set-Cookie header. A consent cookie that only ever appears through document.cookie is on the seven-day clock.

3. Switch on Intelligent Tracking Prevention Debug Mode from the Develop menu. Safari then logs ITP's decisions, including cloaking detections, so you can see whether your consent endpoint was flagged.

4. Resolve the consent host with dig and compare it with your main host. A CNAME to a domain that isn't yours, or addresses on different networks, predicts a seven-day cap.

5. After the change, compare Safari and Chrome for a fortnight: new-versus-returning users, and consent decisions per visitor in your CMP's analytics. The Safari gap should close.

Repeat the check after any DNS, CDN or CMP change. A subdomain that resolved cleanly in March can sit behind a new provider's CNAME by September, and nothing on the page will tell you.

Frequently Asked Questions

Keep Consent Choices Where Safari Can't Reach Them

If Safari visitors are answering your banner every week, start by checking how your consent cookie is set. Kukie.io's scanner lists every cookie your site sets, and its HTTP consent cookies feature writes the choice through a server response with a JavaScript fallback.

Start Free - Scan Your Website