HTTP consent cookies store 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. When the banner's own cookie, _cc_consent, is gone, the banner restores the choice from kk_consent.
Agency plan feature: HTTP Consent Cookies are available on the Agency plan and above. View pricing
Why HTTP consent cookies, and their limits in Safari
Safari keeps a cookie that a page's script writes for up to 7 days. The banner's script writes _cc_consent, so in Safari a visitor who chose more than a week ago can see the banner again.
kk_consent is set by a server, not by a script, so that rule does not apply to it. Safari has two more rules for cookies a server sets, though:
- Since Safari 14, a cookie set by a subdomain that points to another company's domain through a CNAME record is also kept for up to 7 days. Your consent subdomain points to
cookies.kukie.io. - Since Safari 16.4, the same limit applies when the server's IP address differs from your site's in its first half.
So in Safari, kk_consent can expire after 7 days too, like the script cookie. Whether it does depends on how your DNS answers for the consent subdomain, so check it once the setup is done (Step 3 below). In Chrome, Edge and Firefox, _cc_consent lasts for your full consent duration, and the banner reads it first.
How it works
- You switch HTTP Consent Cookies on in the Banner Editor and enter your consent subdomain
- You add two DNS records: a CNAME from
consent.yourdomain.comtocookies.kukie.io, and a TXT record that proves the subdomain belongs to your site - You verify both records in the Banner Editor
- Kukie.io requests a TLS certificate for your subdomain and activates the feature once it is issued, usually within a few minutes
- When a visitor makes or changes a choice, the banner saves it in
_cc_consentand sends the same choice to your subdomain over HTTPS - Your subdomain's response sets
kk_consentwith aSet-Cookieheader, asking the browser to keep it for 365 days - On a later visit, the banner reads
_cc_consentfirst, and restores the choice fromkk_consentonly when_cc_consentis gone
Both cookies are written on every choice, a refusal included, so a refusal is restored the same way as an acceptance. Either way, the choice ends when your consent duration runs out, counted from when it was saved.
Setup
Step 1: Add two DNS records
Switch the feature on and enter your consent subdomain first (Step 2). The card then shows both records with your site's own values. In your DNS provider, add:
1. A CNAME record that routes the subdomain to Kukie.io:
- Type: CNAME
- Name: consent (or any subdomain of your site's domain)
- Target: cookies.kukie.io
- TTL: Auto
2. A TXT record that proves the subdomain belongs to your site:
- Type: TXT
- Name:
_kukie-challenge.consent(the full name is_kukie-challenge.consent.yourdomain.com) - Value: the
kukie-verification=...value shown in the card. It is different for every site, so copy it from the site you are setting up - TTL: Auto
Every Kukie.io customer points their CNAME at the same target, so the CNAME alone cannot show which site a subdomain belongs to. The TXT record can: only whoever controls your DNS can publish it, which stops anyone else from claiming your consent subdomain. Keep both records in place.
The consent subdomain must be on your site's own domain (for a site on shop.example.com, consent.example.com or consent.shop.example.com). DNS changes can take up to 48 hours to propagate, though most providers update within minutes.
Already set up before 27 September 2026? A consent subdomain verified before the TXT record was introduced keeps working. You only need the TXT record when you set up a new subdomain or change it.
Step 2: Configure it in Kukie.io
- Open your site in the Kukie.io dashboard
- Go to Banner Editor > Integrations tab
- Scroll to the HTTP Consent Cookies card and switch Enable HTTP Consent Cookies on. The setup steps appear below it
- Enter your consent subdomain (for example consent.example.com). Each site needs its own subdomain, and two sites cannot share one
- Add the two DNS records the card shows (Step 1), then select Verify DNS records and wait for confirmation
- Kukie.io now requests a TLS certificate for your subdomain. Wait for the Certificate chip to turn green ("Certificate active"). This usually takes a few minutes. Select Check certificate to refresh it
Your banner keeps using the standard JavaScript cookie until both DNS records are verified and the certificate is active, and nothing changes for your visitors in the meantime. Switching the feature off removes the certificate for your subdomain. Switch it back on and the certificate is requested again within minutes.
After saving, Kukie.io regenerates your site's banner bundle to include the HTTP cookie endpoint.
Step 3: Verify
- Open your website in a private window
- Accept cookies in the banner
- Open your browser's developer tools, then Application, then Cookies
- You should see a
kk_consentcookie set on the closest domain shared by your site and the consent subdomain (for example.example.com, or.shop.example.comwhen both live under it) - The cookie holds a JSON object with your consent categories, a consent ID, a timestamp and your site's key, so sibling sites under the same domain never restore each other's choice
- Then check what Safari allows: open the site in Safari, accept, open Web Inspector, then Storage, then Cookies, and read the Expires date of
kk_consent. About a year from today means Safari kept the full lifetime. Seven days from today means Safari applied its limit for cookies set through a CNAME or from another IP range
Technical details
| Aspect | JS cookie | HTTP cookie |
|---|---|---|
| Set by | The banner script | Your consent subdomain (Set-Cookie header) |
| Name | _cc_consent |
kk_consent |
| Lifetime it asks for | Your consent duration (365 days unless you change it) | 365 days |
| Lifetime in Safari | Up to 7 days | Up to 7 days when Safari detects the CNAME or a different IP range, otherwise 365 days |
| HttpOnly | No | No (the banner script reads it) |
| SameSite | Lax | Lax |
| Secure | On HTTPS pages | Yes |
The banner reads _cc_consent first and kk_consent only when _cc_consent is gone. A stored choice the banner refuses to restore, for example after its consent duration has run out, is cleared from both cookies.
Privacy
HTTP consent cookies store only the visitor's consent choice, not tracking data. The cookie holds:
- The choice for each category (for example analytics: true, marketing: false)
- A consent ID (the ID your consent log stores)
- A timestamp
- Your site's key
This is the same information the JS consent cookie holds, plus the site key.
Troubleshooting
DNS verification fails
The message says which record is missing. DNS changes can take up to 48 hours, so wait and try again. Make sure the CNAME target is exactly cookies.kukie.io (not a different subdomain), and that the TXT record sits at _kukie-challenge. followed by your consent subdomain and carries this site's value exactly. A value copied from another of your sites does not verify this one.
"This consent subdomain is already used by another site"
Another site has already verified this subdomain. Each subdomain belongs to one site, so pick a different one for this site (for example consent-shop.example.com). A subdomain that another site only entered, without verifying it, never blocks you.
Cookie not appearing after consent
First check the Integrations tab: the Certificate chip must read "Certificate active". While it says pending, the banner keeps using the JavaScript cookie. Select Check certificate after a few minutes. Then check your browser's developer tools, under Network. Look for a POST request to your consent subdomain (for example https://consent.example.com/api/v1/consent/http). Its response should include a Set-Cookie header.
Certificate error
The chip explains the cause. The usual one is a CNAME that no longer points to cookies.kukie.io: restore the record and select Check certificate. If the message stays, contact support.
Banner still appears again in Safari after 7 days
First make sure the switch is on, the DNS records are verified and the certificate is active (three green checkmarks in the Integrations tab). Then read the Expires date of kk_consent in Safari's Web Inspector, under Storage, then Cookies. If it is 7 days after the cookie was set, Safari applied its limit for cookies set through a CNAME or from another IP range. The banner then appears again after 7 days in Safari, as it does without HTTP consent cookies.
