An HTTP consent cookie is a copy of a visitor's consent choice that a server sets in its response, through a Set-Cookie header, instead of a script writing it with document.cookie. It helps when the script-written cookie is deleted early, which is what Safari does after 7 days without a visit. It is not a way around Safari's tracking prevention: a cookie set through a subdomain that points to another company's servers is capped at 7 days too. A consent banner also cannot switch Safari's blocking of third-party cookies off.
What this means for your site
Safari deletes cookies created in JavaScript, and all other script-writeable storage, after 7 days without user interaction on your site.
A consent cookie set by a server response keeps its own expiry only when the server belongs to your site. Set through a CNAME to a consent provider, or from a server on another company's IP addresses, its expiry is capped at 7 days.
No consent banner can turn off Safari's third-party cookie blocking. A visitor's "Accept all" changes what your site loads, not what the browser allows.
A server-set copy is still useful as a backup: when the script cookie has gone but the server-set one has not, the choice can be restored without asking again.
Check the result in Safari itself: Web Inspector shows the real Expires date of each cookie.
Why Safari visitors see the banner again
Apple introduced Intelligent Tracking Prevention (ITP) in Safari in 2017, and the rules have grown stricter since. The one that matters for consent is described on WebKit's tracking prevention page: ITP deletes all cookies created in JavaScript, and all other script-writeable storage, after 7 days of no user interaction with the website.
Most consent banners store the choice in a cookie their own script writes. A visitor who accepts on a Monday and does not come back for more than a week can find the banner waiting again. A visitor who returns and interacts within those 7 days keeps the choice. The full mechanics, including the 24-hour cap after link decoration, are in the guide to Safari ITP and the reappearing banner.
Brave goes further and blocks many third-party cookies outright. Safari itself blocks all third-party cookies by default. A third party gets access only through the Storage Access API or a temporary fix for pop-ups.
A banner that returns too often has a cost. Visitors who are asked again and again tend to dismiss it without reading. Every lost choice also means Google Consent Mode starts from the denied default on the next page view, until the visitor chooses again.
What a server-set cookie changes
A cookie set by a server in an HTTP response is not "created in JavaScript", so the 7-day deletion rule for script-writeable storage does not cover it. Where the server that answers belongs to the site the visitor is on, Safari respects the cookie's own Max-Age or Expires. Chrome caps any cookie at 400 days, a limit it introduced in Chrome 104 in August 2022.
In practice the flow looks like this:
A visitor makes a choice in the cookie banner.
The banner sends the choice to an endpoint on a subdomain of your site, for example
consent.yourdomain.com.That endpoint answers with a
Set-Cookieheader that holds the consent state and its own expiry.On later page views, the banner reads the stored choice and does not ask again while it is valid.
Whether step 3 escapes Safari's 7-day limit depends on step 2: who answers for that subdomain.
Where Safari still caps the cookie at 7 days
WebKit calls the problem CNAME cloaking. Trackers asked site owners to point a first-party subdomain at the tracker's own servers through a CNAME record, so their cookies looked first-party. Since Safari 14 in 2020, ITP detects a subdomain that resolves through a CNAME to another company's domain and caps the expiry of every cookie set in that HTTP response at 7 days. WebKit's tracking prevention page applies the same 7-day cap to third-party IP address cloaking, where the subdomain answers from servers that are not your site's.
A consent subdomain that is a CNAME to a consent provider's host fits that pattern. Safari does not look at what the cookie holds, so a consent choice is treated like a tracking identifier. The cap applies whether or not the provider uses the cookie for tracking.
Which Safari limit applies to a consent cookie
JavaScript cookies compared with HTTP cookies
The table below sets out how the two ways of writing a cookie differ.
| Attribute | JavaScript cookie (document.cookie) | HTTP cookie (Set-Cookie header) |
|---|---|---|
| Set by | Client-side script in the browser | Server response header |
| Safari ITP | Deleted after 7 days without user interaction | Keeps its Max-Age or Expires, unless set through a third-party CNAME or IP address (then capped at 7 days) |
HttpOnly flag | Cannot be set | Can be set, which hides the cookie from scripts |
| Exposure to cross-site scripting | Readable and writable by any script on the page | HttpOnly cookies are hidden from scripts |
| Longest lifespan | Up to 400 days in Chrome, 7 days without interaction in Safari | Up to 400 days in Chrome. In Safari, it depends on who answers for the subdomain |
| Needs server infrastructure | No | Yes (a subdomain, through a CNAME or a proxy) |
An HttpOnly cookie cannot be read or changed by scripts running on the page. A consent cookie that the banner itself must read cannot be HttpOnly, so this advantage only applies where the server, not the banner, reads the choice.
A CNAME (canonical name) DNS record maps one domain name to another. When consent.yourdomain.com is a CNAME to a provider's host, requests to that subdomain reach the provider's servers, while the browser shows your domain as the address.
A consent cookie holds a visitor's own choice, such as analytics granted and marketing denied, not a tracking identifier. That difference in purpose is real, but Safari's defence does not test it: it looks at where the subdomain resolves. For Safari, a consent CNAME and a tracking CNAME look the same.
How Kukie.io sets an HTTP consent cookie
Kukie.io offers HTTP consent cookies as a second copy of each choice, on the plans the feature page lists. As of October 2026, the setup is:
In Banner Editor, open Integrations, turn on Enable HTTP Consent Cookies and enter your consent subdomain, for example
consent.example.com.In your DNS, add a CNAME named
consentthat points tocookies.kukie.io.Add a TXT record named
_kukie-challenge.consentwith the value the dashboard card shows. The CNAME target is shared by many sites, so the TXT record is what proves the subdomain is yours.Select Verify DNS records. Kukie.io then requests a certificate for the subdomain, usually active within a few minutes, and the card shows its status.
Until the certificate is active, the banner uses its script cookie alone. The HTTP consent cookies setup guide covers each step.
Because the subdomain is a CNAME to cookies.kukie.io, Safari can cap the server-set cookie at 7 days, like the script cookie. Kukie.io's own feature page says so. To see what your setup gets, open your site in a private Safari window, accept or reject, then open Web Inspector, go to Storage and then Cookies, and compare the Expires date of kk_consent with today.
Two copies of the choice, and which one is read
With the feature on and the certificate active, every choice is stored twice. The banner writes its own cookie, _cc_consent, and sends the choice to your consent subdomain, which sets kk_consent in its response with a requested lifetime of 365 days, Secure and SameSite=Lax.
The banner reads _cc_consent first. If that cookie has gone, it restores the choice from kk_consent. Refusals are written the same way as acceptances, so a "Reject all" is restored too, and the cookie holds the category choices, a consent ID, the time and your site key, with no tracking data.
If the subdomain stops answering, the banner keeps working with its script cookie. Visitors see no error. They are only asked again sooner in Safari.
Consent cookies and the law
Storing a consent choice in an HTTP cookie does not change what the ePrivacy Directive requires. Article 5(3) of the ePrivacy Directive requires consent for storing information on a visitor's device, with an exemption for storage that is strictly necessary for a service the visitor has explicitly requested.
Regulators treat the cookie that remembers the choice as exempt. The CNIL, France's data protection authority, lists trackers that keep the choice a visitor made about trackers among those that need no consent, in its guidance on what the law says about cookies. Asking for consent to store the consent cookie would be circular.
Repeated prompts are a consent fatigue problem rather than a legal one. Visitors who see the same banner on every visit read it less carefully, which weakens the informed choice the law asks for.
Short answers on HTTP consent cookies and Safari
Do HTTP consent cookies bypass Safari ITP?
No. Safari caps cookies set through a third-party CNAME, or from a server on another company's IP addresses, at 7 days, so a CNAME to a consent provider does not reliably escape ITP. Only a cookie set by servers that belong to your site keeps its own expiry.
Can a cookie consent banner turn off Safari's third-party cookie blocking?
No. Safari blocks third-party cookies by default and no website setting or consent choice changes that. A visitor's consent decides what your site loads, not what the browser allows.
What is a consent cookie?
A consent cookie is the small cookie a consent banner uses to remember which categories a visitor accepted or rejected. It holds the choice, not a tracking identifier, and regulators such as the CNIL treat it as exempt from consent.
Is a CNAME for consent cookies the same as CNAME cloaking?
The purpose differs, because a consent cookie stores the visitor's own choice rather than a tracking identifier. Safari does not judge the purpose, though: it caps cookies from any subdomain that resolves to another company's domain, including a consent CNAME.
What happens if the consent subdomain stops working?
The banner keeps storing the choice in its own script cookie, so visitors see no error. In Safari they may be asked again after 7 days without a visit.
Will HTTP consent cookies affect page speed?
Barely. The browser makes one extra request to the consent subdomain when a visitor chooses, and the cookie adds a few hundred bytes to later requests to that subdomain. It does not delay the page or change Core Web Vitals.
Check how long your consent lasts in Safari
If Safari visitors keep seeing your banner, start by measuring: Web Inspector shows the real expiry of every consent cookie on your site. Kukie.io stores each choice with the banner's own cookie and, where you set it up, a server-set copy, alongside cookie blocking and scanning.
