A cookie policy generator reads your website, finds the cookies and trackers it loads, and writes the declaration for you. Name, provider, purpose, duration, category. That is the boring table every privacy regulator expects to see, and it is the part most sites either skip or copy from someone else.
This guide covers what belongs in a cookie policy, why the hand written version stops being true almost immediately, and how to generate a cookie declaration for free without an account.
What is a cookie declaration?
A cookie declaration is the list of cookies your website sets, with what each one does and how long it lasts. It usually sits inside your cookie policy or privacy policy. Its job is to let a visitor see exactly what is being stored on their device before they agree to it.
People mix up two things here. The cookie policy is the page of text explaining your approach. The declaration is the table inside it. You need both, but the table is the part that has to stay accurate, because it is the part that changes every time someone adds a script.
What has to be in a GDPR cookie policy?
Under GDPR and the ePrivacy Directive, a cookie policy has to tell visitors what you store, who receives it, why, for how long, and how to change their mind. Vague categories are not enough. The regulator's test is whether a normal person could read your policy and understand what is happening to them.
In practice, that means covering:
- Every cookie and similar technology you use. The EDPB guidance on the technical scope of the ePrivacy rules makes clear this is not just cookies. Local storage, pixels and device fingerprinting count too.
- Who sets it. First party (you) or third party (Google, Meta, your chat widget).
- What it is for, in plain words. "Analytics" is a category, not a purpose.
- How long it lasts. Session, 30 days, two years.
- Which category it falls in, since that decides whether it needs consent at all.
- How to withdraw consent, and it has to be as easy as giving it.
That last point is the one people forget. If your banner has an Accept button and no way back, the consent is not valid. Consentify handles this with a revoke element: you drop <div id="revoke-consent-btn"></div> on your privacy page and the banner reopens when a visitor clicks it.
Why hand written cookie policies stop being true
Almost every cookie policy we see was accurate on the day it was written. Then marketing added a Meta Pixel. Someone embedded a YouTube video. A new chat widget went live. None of those people opened the policy page.
Our own scan data backs this up. When we scanned 1,775 websites, sites that had a consent banner leaked a tracking cookie before consent more often (37%) than sites with no banner at all (28%). A banner and a policy both suggest someone thought about this once. They do not prove anyone has looked since.
A policy that lists three cookies while the site sets eleven is worse than no policy. It is a written statement that is easy to disprove in about ten seconds.
How does a cookie policy generator work?
You enter your domain. The tool loads your site the way a first time visitor's browser does, records every cookie, tracker and third party request, then matches what it finds against a database of known trackers to fill in the purpose and duration for each one. You get back a declaration you can paste into your policy page.
The matching step is what separates a useful generator from a form that just formats whatever you type. Our generator checks against the same tracker database the scanner uses, which covers over 85 trackers with authored cookie tables rather than guesses.
Step 1: See what you actually load
Run a free GDPR scan first. It takes about ten seconds and gives you the full list, including the trackers that fire before anyone clicks anything. Fixing the site is easier before you write about it.
Step 2: Generate the declaration
Enter the same domain in the generator. You get an HTML table with each cookie, its provider, purpose and duration, ready to paste. No account needed.
Step 3: Make it self updating
This is the part worth doing properly. If you use Consentify, you can drop <div id="consentify-cookie-declaration"></div> on your privacy page instead of pasting a static table. The declaration is then built from the integrations configured on your domain, so it changes when your setup changes. Nobody has to remember to update it.
Can you copy a cookie policy from another website?
No, and it is a bad idea for a practical reason rather than a legal one. Their policy describes their cookies. If you copy a policy listing tools you do not use, and it omits the ones you do, you have published an inaccurate statement about your own data processing. That is the specific thing regulators penalise.
Templates are fine as a skeleton for the explanatory text. The table has to come from your site.
Where the policy and the banner have to agree
Your policy says analytics cookies only run after consent. Your site loads Google Analytics on page load. Both statements cannot be true, and only one of them is visible in a browser's network tab.
This is why the declaration should be generated from the same configuration that controls the banner. In Consentify, the integrations you add to a domain do two things at once: they stay blocked until the visitor accepts, and they populate the cookie declaration. One source of truth, so the page and the behaviour cannot drift apart.
If you want the legal background rather than the implementation detail, our GDPR cookie consent guide covers what the regulation asks for and why.
How often should you update it?
Any time you add or remove a script, and otherwise once a quarter. The quarterly check exists to catch the changes nobody told you about, which in our experience is most of them.
The ICO's storage and access guidance, finalised in 2026, is explicit that transparency obligations are ongoing rather than a one off publication. The easiest way to meet that is to stop maintaining the list by hand.
Ready to stop editing tables by hand? Try Consentify free, one domain, no watermark, no time limit.