Generate a ready-to-paste HTML + JavaScript cookie consent banner for your website. Blocks Google Analytics and Meta Pixel until consent is given. GDPR-compliant, no CDN, no monthly fee.
The policy tells users what you do. The banner is what GDPR actually requires you to do first.
GDPR requires that non-essential cookies — analytics, advertising, personalisation — are not set until after the user gives consent. This is the prior consent requirement of the ePrivacy Directive, and it applies regardless of whether you have a cookie policy. A cookie policy alone is a disclosure document. It tells users what you use. But the law requires you to ask first, and to not load the scripts until the answer is yes. A cookie policy without a functioning consent mechanism does not satisfy Article 5(3) of the ePrivacy Directive.
The common mistake is having a banner that says "We use cookies" while GA4, Meta Pixel, and Hotjar load silently in the background before the user has clicked anything. This is not compliant — it is decorative. The ICO has specifically issued enforcement notices to publishers for exactly this pattern: showing a banner while non-essential cookies load unconditionally. The test is not whether a banner is present. The test is whether scripts are blocked until consent is given.
The question of legitimate interest vs. consent is not as simple as many site owners hope. Most analytics cookies cannot rely on legitimate interest as a lawful basis under the ePrivacy Directive. The Directive requires consent for any storage of or access to information on a user's device unless strictly necessary. Google itself acknowledged this when building Consent Mode v2: proper consent is required for GA4 data to be used for advertising purposes, and Google's own documentation says consent must be collected before GA4 initialises for advertising features.
The technical requirement matters here. GA4 Consent Mode v2 uses a gtag consent default call to signal to Google what users have and have not consented to. Meta Pixel's data use restriction API allows you to flag consent state before events fire. These only work when your banner correctly signals consent to these scripts before they load — not after. A banner that fires after page load, after scripts have already initialised, cannot retroactively restrict what those scripts collected on first page load. Timing is the whole point.
Our generated banner blocks GA4 and Meta Pixel until the user explicitly accepts. Scripts are held in a deferred queue and only fired after the consent callback resolves — never before.
GDPR and the ePrivacy Directive require prior informed consent before analytics or advertising scripts set cookies on visitor devices. A policy alone does not satisfy this requirement — a functional blocking banner does.
Bad banners display a message while scripts load anyway. They use pre-ticked boxes, hide the reject option, or make rejection harder than acceptance. The ICO and CNIL have fined companies specifically for these dark patterns.
Our generated banner holds all analytics and advertising scripts in a queue until the user accepts. GA4 Consent Mode v2 is initialised first. Rejection means those scripts never run on that page load.
Every feature you need for a compliant, self-hosted cookie consent banner — no dependencies, no subscription.
No jQuery, no npm, no CDN link required. Pure vanilla JS that works in every modern browser without any build step or package manager.
All banner styles are injected inline. There's no separate CSS file to host or link. Drop the script in and it works, styled exactly to your color choices.
Consent is stored in both localStorage and a first-party cookie for 180 days. Returning users won't see the banner again until their consent expires or they clear their data.
The banner fires gtag('consent', 'default', {...}) before any GA4 script loads, signalling denied consent. On accept, gtag('consent', 'update', {...}) is called to unlock analytics and ad storage.
Meta Pixel is only injected into the page after explicit consent. The fbq() stub is not initialised until the user clicks Accept, preventing any pixel events or cookies from firing without consent.
Both buttons are equally prominent — no dark patterns, no buried reject option. Equally accessible Accept and Reject buttons meet GDPR's requirement that withdrawal of consent is as easy as giving it.
The banner automatically includes links to your Privacy Policy and Cookie Policy URLs. GDPR requires that consent is informed — users must be able to read what they're consenting to before deciding.
The banner uses semantic HTML, proper ARIA roles, keyboard-navigable buttons, and sufficient colour contrast. Accessibility is a legal requirement in the EU and many other jurisdictions.
Three platforms, three sets of steps. In all cases, paste the script before the closing body tag.
</body> tag</body> tag<script> block immediately before itThe technical and legal questions that come up when you're implementing cookie consent properly
Consent Management Platforms charge monthly fees for a problem you can solve once with self-hosted code.
| Feature | FreeTOS | CookieYes | Cookiebot |
|---|---|---|---|
| Price | Free | Free (with branding) | €9/month |
| Banner Script | Yes | Yes | Yes |
| Removes Branding | N/A (no branding) | $15/month | Paid |
| Blocks Scripts (GDPR) | Yes | Yes | Yes |
| Account Required | No | Yes | Yes |
| Self-hosted Code | Yes | No (CDN) | No (CDN) |
| Consent Logging | No (client-side only) | Paid | Paid |
CDN-based solutions like CookieYes and Cookiebot create a dependency: if their CDN goes down, your banner breaks, which can temporarily expose your site to non-compliance. Self-hosted code never breaks due to a third-party outage.