Skip to content
Start free Sign in

HTTP consent cookies

A second copy of each choice.

With HTTP consent cookies, your own consent subdomain also stores each choice, in a cookie its server sets. When the banner's own cookie is gone, the choice comes back from there.

HTTP consent cookies are available on the Agency and Unlimited plans. Browser rules checked on .

How it works

One choice, stored twice.

The banner keeps its own cookie, and your consent subdomain keeps a copy the browser receives from a server, not from a script.

  1. The visitor chooses

    The banner saves the choice in _cc_consent and sends the same choice to your consent subdomain.

  2. Your subdomain answers

    Its response sets kk_consent on your domain for 365 days, Secure and SameSite Lax. The banner can read it.

  3. A later visit

    If _cc_consent is gone, the banner restores the choice from kk_consent. It still ends when your consent duration runs out.

Side by side

Two cookies, one choice.

Both hold the same choice. What differs is who sets each one, and so which browser rules apply to it.

The banner's cookie and the HTTP consent cookie compared
Detail_cc_consentkk_consent
Set by The banner's script Your consent subdomain, in its response
Asks to be kept for Your consent duration, 365 days unless you change it 365 days
Domain Your site, or your domain with subdomain sharing on The closest domain your site and the subdomain share
Read by the banner Yes Yes, when _cc_consent is gone
Secure and SameSite Secure on HTTPS pages, SameSite Lax Always Secure, SameSite Lax
Holds The choice, a consent ID and the time The same, plus your site key

Browser limits

Browsers set their own limits.

A cookie lives as long as the browser allows, not only as long as the site asks. These are Safari's rules that apply here, checked on .

  • Safari, since 2019

    Cookies written by script

    Safari keeps a cookie that a page's script writes, such as _cc_consent, for up to 7 days.1

  • Safari 14 and later

    Cookies through a CNAME

    A cookie set by a subdomain that points to another company's domain through a CNAME record is kept for up to 7 days too.2 Your consent subdomain points to cookies.kukie.io.

  • Safari 16.4 and later

    Cookies from another server

    The same limit applies when the server's IP address differs from your site's in its first half.3

What this means for Safari. kk_consent can expire after 7 days, like the script cookie. Whether it does depends on how your DNS answers for the consent subdomain, so check it in Safari once it is set up. Where the script cookie lasts its full time, the banner reads that one and kk_consent stays a backup.

Check your cookie's expiry in Safari

Built in

Your subdomain, and only yours.

Kukie.io checks that the subdomain is yours before it sets a single cookie on it, and keeps each site's choices apart.

Proof that it is yours

Verification needs the CNAME and a TXT record whose value is unique to your site, so no one else can claim your subdomain.

Only your pages write it

The subdomain answers only on its verified address, and only to pages on your site.

A certificate, requested for you

Once both records check out, Kukie.io requests the TLS certificate. Until it is active, the banner keeps its script cookie alone.

Your site key inside

Sites under one domain never restore each other's choice, because each cookie carries its own site's key.

One subdomain per site

Each site has its own consent subdomain. A subdomain another site has verified cannot be used again.

A refusal is kept too

Reject all is written the same way as an acceptance, and a choice the banner refuses to restore is cleared from both cookies.

Check it yourself

See what your setup gets.

Two checks once the certificate is active: the response in any browser, and the expiry in Safari.

1. The response

Select Accept all, open Network and find the request to your consent subdomain. Its Cookies tab lists kk_consent:

The request goes to your own subdomain, at /api/v1/consent/http.

2. The expiry in Safari

In Safari, open Web Inspector, then Storage, then Cookies. Compare the Expires date of kk_consent with today:

Use a private window, so an earlier choice does not answer for you.

Setup

Set it up in three steps.

A subdomain of your site's domain and access to your DNS are all you need.

  1. Step 1: Turn it on

    In your site's Banner Editor, open Integrations, turn on Enable HTTP Consent Cookies and enter your consent subdomain.
  2. Step 2: Add two DNS records

    Add the CNAME and the TXT record the card shows, with your site's own values.
  3. Step 3: Verify and wait for the certificate

    Select Verify DNS records. The certificate is usually active within a few minutes, and the card says when.

The two DNS records, for consent.example.com

The DNS records for a consent subdomain
TypeNameValue
CNAMEconsentcookies.kukie.io
TXT_kukie-challenge.consentThe value the card shows, unique to your site

Documentation

Guides to setting it up.

Step-by-step guides in the Help Centre.

  • HTTP consent cookies

    Set up the subdomain, the two DNS records and the certificate, with fixes for each step.

  • Consent records

    Every choice is also recorded with a consent ID you can look up.

  • Region rules

    Set the consent model and the consent duration for each region.

Questions about HTTP consent cookies

What are HTTP consent cookies?
A second copy of each visitor's choice, in a cookie called kk_consent that your own consent subdomain sets with a Set-Cookie header. The banner reads it when its own cookie, _cc_consent, is gone.
Do they keep a choice for a year in Safari?
Not always. Safari keeps cookies written by a page's script for up to 7 days. It applies the same limit to a cookie set by a subdomain that points to another company's domain through a CNAME record, and your consent subdomain points to cookies.kukie.io. Check the cookie's expiry in Safari after setup.
What do I need to set them up?
A subdomain of your site's domain, such as consent.example.com, and access to your DNS. You add a CNAME record that points to cookies.kukie.io and a TXT record that proves the subdomain is yours.
Why is the TXT record needed?
Every Kukie.io customer points a CNAME at the same address, so the CNAME alone cannot show whose subdomain it is. Only someone who controls your DNS can publish the TXT record.
How long does the certificate take?
Kukie.io requests it once both records check out, and it is usually active within a few minutes. Until then the banner keeps using its script cookie alone.
What does kk_consent contain?
The choice for each category, a consent ID, the time it was written and your site's key. It holds no tracking data.
Is a refusal stored as well?
Yes. Reject all is written the same way as an acceptance, so a refusal is restored too.
Can two of my sites share one consent subdomain?
No. Each site needs its own. Sites under the same domain can each set kk_consent, and each restores only the one that carries its own site key.
What happens if I switch them off?
The banner goes back to its script cookie alone, and Kukie.io removes the certificate for your subdomain. Switch them on again and the certificate is requested again within minutes.
Which plans include HTTP consent cookies?
HTTP consent cookies are available on the Agency and Unlimited plans. The pricing page lists what each plan includes.

Keep a second copy of every choice.

Set up your consent subdomain in a few minutes, then check in Safari what your setup gets.

Footnotes

Kukie.io provides tools to collect and record consent. It is not legal advice, and using it does not by itself make a website compliant with any law.

  1. 1. WebKit, 'Intelligent Tracking Prevention 2.1', 21 February 2019: persistent cookies created through document.cookie are capped at a 7-day expiry. Read WebKit's post (opens in a new tab).Back to footnote 1 in the text
  2. 2. WebKit, 'CNAME Cloaking and Bounce Tracking Defense', November 2020, for Safari 14: cookies set in responses from a first-party subdomain that resolves through a third-party CNAME are capped at 7 days. Read WebKit's post (opens in a new tab).Back to footnote 2 in the text
  3. 3. Safari 16.4, April 2023. The rule is not in Apple's release notes. It is in WebKit's source code, and server-side tagging providers documented it the same year.Back to footnote 3 in the text

Listed on