How to Write a Cookie Policy (2026): The Complete Guide

There's a common misconception that cookie policies are a European problem. They're not. California requires disclosure of cookies collecting personal information and a 'Do Not Sell or Share My Personal Information' link that must work. Virginia, Colorado, Connecticut, Utah, Texas, Oregon, and 13 other US states have comprehensive privacy laws with similar requirements. Minnesota's law (effective 2025, cure period expired January 31, 2026) carries $7,500 per-violation civil penalties. Even if you never see a European visitor, if you have analytics, ad pixels, or embedded third-party content, you have cookie obligations.

The practical triggers for needing a cookie policy:

• You have EU, UK, or EEA traffic of any kind (ePrivacy Article 5(3) + GDPR extraterritorial reach under Article 3)
• You have California residents as users and use any advertising or analytics cookies (CCPA/CPRA)
• You have users in Virginia, Colorado, Connecticut, Utah, or any of 15+ other US states with comprehensive privacy laws
• You have Brazilian users (LGPD) or Indian users (DPDP Act)
• You want to use Google Analytics, Google Ads, or any Google marketing product in the EEA (Consent Mode v2 mandate, March 2024)
• You run programmatic advertising via IAB-member networks (TCF v2.3 mandatory since Feb 28, 2026)

In practice, these collectively describe almost every commercial website. The question isn't whether you need a cookie policy, but how comprehensive it needs to be.

The consequences of getting this wrong have escalated. CNIL fined SHEIN €150 million in 2024 for cookie dark patterns - making the Reject button harder to find than Accept. Sephora settled for $1.2M after failing to honor Global Privacy Control signals. CNIL's combined cookie-related fines between December 2022 and December 2024 exceeded €139 million. This is no longer a warning-letter topic.

Before you can write a cookie policy, you need to understand how cookies are classified. The UK International Chamber of Commerce developed a four-category taxonomy that's been adopted by the UK Information Commissioner's Office, the CNIL, the European Data Protection Board, and virtually every consent management platform. Every cookie on your site falls into one of four buckets:

1. Strictly Necessary.

Cookies without which the site cannot function. Session authentication tokens, CSRF protection, shopping cart state, load balancing, and the consent cookie itself. These are exempt from consent under ePrivacy Article 5(3) - you can set them without asking. The bar for 'strictly necessary' is narrow: the CNIL and ICO have both rejected attempts to classify analytics cookies as strictly necessary, even when site owners argued the analytics were 'essential for the business.' The test is whether the cookie is essential for the user-requested service, not essential for your business.

2. Functional.

Cookies that remember user choices (language, region, UI preferences, font size) to provide an enhanced experience. These require consent in the EU and UK. In the US, they require disclosure but not necessarily opt-in. The key distinction: a functional cookie remembers something the user chose, while a strictly necessary cookie enables something the user requested.

3. Analytics / Performance.

Cookies that measure how visitors use the site - page views, error messages, load times, user flows, session recordings. Google Analytics, Mixpanel, Amplitude, Hotjar, and Microsoft Clarity all fall here. These require consent in the EU/UK. The CNIL has fined multiple sites specifically for categorizing Google Analytics as strictly necessary - don't make that mistake. In the US, analytics cookies require disclosure and opt-out rights for CCPA-covered processing.

4. Marketing / Advertising.

Cookies that deliver targeted ads, measure ad campaign effectiveness, or build advertising profiles. Meta Pixel, Google Ads conversion tracking, LinkedIn Insight Tag, TikTok Pixel, and retargeting cookies fall here. These require the strongest consent in the EU/UK (informed opt-in with granular choices). In California, they trigger 'sale' or 'sharing' designations under CPRA, requiring Do Not Sell or Share mechanisms and GPC signal honoring.

Your cookie policy should present these four categories clearly and list which specific cookies fall into each. Grouping cookies by category (not by provider) is the presentation pattern that matches both ICO guidance and modern CMP conventions - and it's what users actually understand.

Cookie consent works fundamentally differently across regions. The default assumption differs. The required disclosures differ. The mechanism for capturing consent differs. If you have global traffic, your cookie policy needs to address all of this.

The European Union (opt-in).

ePrivacy Article 5(3) requires prior informed consent before any non-essential cookie is placed on a user's device. GDPR defines consent as freely given, specific, informed, and unambiguous. That means: no pre-ticked boxes, no bundled consent ('accept marketing to continue'), no cookie walls blocking access if the user declines, no dark patterns making Reject harder than Accept. The consent banner must be shown before any non-essential cookie fires. Consent must be as easy to withdraw as to give.

The United Kingdom (opt-in with narrow exemptions).

UK GDPR and PECR originally mirrored EU requirements exactly. The Data Use and Access Act 2025 (effective June 2025) added five narrow exemptions for low-risk cookies: limited statistical purposes, security, service-authentication, interface-customization, and software updates. Analytics and advertising cookies still require prior consent. The ICO has been clear that the exemptions are narrow and should not be construed expansively. In practice, UK cookie policies look almost identical to EU policies.

California (opt-out).

CCPA/CPRA uses an opt-out model. Cookies may be set by default, but visitors must be able to opt out of the 'sale' or 'sharing' of personal information. CPRA's definition of 'sharing' includes cross-context behavioral advertising, which captures virtually all advertising cookies. A conspicuous 'Do Not Sell or Share My Personal Information' link is required, and the Global Privacy Control browser signal must be honored as a valid opt-out request. The California Privacy Protection Agency enforces; fines run up to $7,500 per intentional violation.

Other US states (opt-out with UOOMs).

Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana, Delaware, Iowa, Nebraska, New Hampshire, New Jersey, Tennessee, Minnesota, Maryland, Rhode Island, Kentucky, and Indiana all have comprehensive privacy laws now. Most follow California's opt-out model with honor requirements for Universal Opt-Out Mechanisms (UOOMs) - of which GPC is the only widely deployed example. Sensitive data processing typically requires opt-in consent in these states.

Brazil (opt-in, Portuguese mandatory).

LGPD requires opt-in consent for non-essential cookies and mandates Portuguese-language notice. The Brazilian Data Protection Authority (ANPD) has been steadily increasing enforcement activity. The generator produces a fully-translated Portuguese banner variant when Brazil is selected.

India (opt-in, multilingual).

India's Digital Personal Data Protection Act (DPDP) came into force with rules finalizing through 2026-2027. Consent must be free, informed, specific, and easy to withdraw. Notice must be available in English plus any of 22 official Indian languages. From November 2026, Consent Managers must register with the Data Protection Board; critically, only India-incorporated entities qualify as Consent Managers, which excludes foreign CMPs.

If your site monetizes through programmatic advertising and serves EU users, the IAB Europe Transparency and Consent Framework is non-negotiable. Google requires a Google-certified CMP that integrates with TCF for advertisers serving EU users (this has been mandatory since July 2024). Publishers monetizing through programmatic ad exchanges need TCF to get access to the major DSPs.

The v2.3 update, released in April 2025, resolved a long-standing ambiguity about whether vendors had actually been disclosed to users. Previous versions relied on implicit signaling: if a vendor was on the allowed list, it was assumed disclosed. Regulators increasingly pushed back on this, arguing it violated GDPR's transparency requirement.

v2.3 introduces a mandatory Disclosed Vendors segment in the TC (Transparency and Consent) string - a binary bitfield indicating, for each vendor, whether they were actually shown to the user in the CMP interface. As of March 1, 2026, any TC string without a valid Disclosed Vendors segment is non-compliant. If you're a publisher or vendor relying on TCF, this is an enforcement-level problem.

What your cookie policy needs to say if you participate in TCF v2.3:

• That you participate in the IAB Europe Transparency and Consent Framework (TCF v2.3)
• That consent choices are encoded into a TC string shared with participating vendors
• That as of March 1, 2026, the TC string includes a Disclosed Vendors segment
• Where users can access the TCF preference center to review and change their choices
• That withdrawing consent through TCF will stop processing by vendors that respect the signal

The generator produces all of this automatically when you enable TCF support in the Consent step. You still need a TCF-certified CMP to actually generate compliant TC strings - the policy is the disclosure, not the implementation.

Here's the awkward truth about most cookie policies: they don't accurately describe the cookies the site actually sets. Templates copied from competitors list cookies the site doesn't use. Cookies that appeared after a marketing team added a new embed never made it into the policy. This is the exact pattern DPAs flag in sweep investigations.

A real cookie audit takes 30 minutes and produces an accurate inventory. Do this before publishing any cookie policy:

1. Open your site in a clean browser profile (private/incognito, no extensions, no cached cookies)
2. Open DevTools (F12 in Chrome/Firefox/Edge; Option+Cmd+I in Safari)
3. Go to the Application tab (Chrome) or Storage tab (Firefox), expand Cookies, select your domain
4. Load the homepage. Screenshot or export the list of cookies set at this point
5. If you have a consent banner, the above should be empty or show only strictly-necessary cookies. If it shows analytics or marketing cookies, your banner is leaking
6. Accept cookies through your banner. Reload. Screenshot again
7. Visit 5-10 different pages: a blog post, a product page, the checkout, a contact form, an article with embedded video
8. Check for cookies from sub-pages that the homepage doesn't set (common with embedded YouTube, embedded forms, embedded payment flows)
9. Also check Local Storage and Session Storage - many modern tools use these instead of HTTP cookies
10. Cross-reference every cookie with the generator's pre-populated services. Anything missing goes in the custom cookie form

The pre-consent check is critical. If your banner allows cookies to fire before the user clicks Accept, you have an ePrivacy Article 5(3) problem independent of what your policy says. Regulators test this. CMPs often ship with defaults that fire GA4 or GTM before consent - verify yours doesn't. Google Consent Mode v2, configured properly, should block non-essential data collection until consent is granted.

Once you have the audit inventory, the generator handles the policy writing. Every selected service adds its known cookies with name/provider/purpose/duration pre-filled. For custom cookies (first-party cookies you've set yourself, or niche services not in the database), use the custom cookie form in the Cookies step.

These three things are often confused but they're technically distinct:

The cookie policy is a written disclosure document. It explains what cookies you use, why, for how long, how to control them, and what rights visitors have. It lives at a URL (typically /cookies/ or /cookie-policy/). It's the most comprehensive document. This is what the generator produces.

The consent banner is the UI that captures user choices. It appears on first visit and remains accessible (typically via a footer link). It's a combination of UI and JavaScript that conditionally loads scripts based on consent. The generator produces the copy for the banner, but not the JavaScript implementation - that's a separate concern handled by your CMP or DIY code.

The cookie declaration is the specific table listing every cookie (name, provider, purpose, duration, category). It lives inside the cookie policy, but is often also shown inside the preference center so users can drill down without leaving the banner. The generator produces this as a formatted table inside the policy.

The layered notice approach, recommended by the UK ICC and endorsed by both the CNIL and ICO, is to present information at three depth levels:

• Short banner at first visit (100-200 words, main purposes, Accept/Reject/Manage)
• Preference center expandable from the banner (category toggles with brief descriptions)
• Full cookie policy linked from both (comprehensive disclosure document)

This avoids the 'wall of legalese' failure mode that regulators criticize, while still providing complete information for users who want it.

The mechanism of obtaining consent is where most cookie-policy gaps turn into actual enforcement problems. The policy document itself is easy. The consent capture mechanism is where compliance breaks.

Opt-in consent (EU/UK/BR/IN). Consent must be the result of an affirmative action. Clicking Accept on a banner is affirmative; continuing to scroll is not. Closing the banner without clicking anything is not consent - regulators have been explicit about this. Pre-ticked boxes are not consent. 'Consent by continuing to use the site' is not consent.

Opt-out (CCPA/CPRA and most other US states). Cookies may be set by default, but a mechanism must be available to stop 'sale' or 'sharing' of personal information. The CCPA/CPRA 'Do Not Sell or Share My Personal Information' link is required; it must appear in the footer of every page (or a conspicuous alternative). Clicking it must actually work: stop firing the relevant cookies, signal opt-out to connected third parties, and honor the signal across the session.

Global Privacy Control (GPC). GPC is a browser signal (header + DOM property) that indicates the user wants to opt out of tracking. The California AG has stated GPC qualifies as a valid opt-out under CCPA/CPRA. Colorado, Connecticut, and most newer state laws require honoring UOOMs, of which GPC is the main example. If your site serves California traffic, you must honor GPC - not just disclose that you do, but actually implement the blocking.

Dark patterns. The CNIL, ICO, EDPB, and FTC have been increasingly aggressive about UI dark patterns in cookie banners. Specific patterns regulators have cited:

• Accept button prominently styled, Reject button small/grey/hidden in a menu - SHEIN fined €150M
• Accept on the banner but Reject requiring a separate 'Manage preferences' click - CNIL has fined this multiple times
• Pre-ticked consent boxes - illegal under GDPR (Planet49 ruling, CJEU C-673/17)
• Cookie walls blocking content unless consent is given - EDPB guidelines 05/2020 prohibit this
• Consent being implied from continued browsing - never valid under GDPR
• 'Accept' defaulting to all purposes, 'Reject' only opting out of some - Fineline reasoning the CNIL rejects

The practical test: Accept and Reject should require the same number of clicks, have the same visual prominence, and have equally clear labels. If a user scanning your banner for 0.5 seconds can immediately see both options equally, you're probably fine. If they see only Accept clearly, you're probably not.

When auditing real sites, a consistent pattern emerges: certain services set cookies without the site owner realizing. These tend to be the embedded third-party tools that feel invisible. Specific services to check for:

• YouTube embeds - even a single embedded video sets VISITOR_INFO1_LIVE, YSC, PREF, and VISITOR_PRIVACY_METADATA. Use youtube-nocookie.com domain to avoid some, but the site still drops cookies once playback begins
• Google Fonts - if loaded from fonts.googleapis.com, it exposes user IP to Google. Some EU DPAs have ruled this requires consent (German 2022 ruling). Self-host the fonts or use system fonts
• Google reCAPTCHA - sets cookies for risk scoring. Necessary in the narrow sense (prevents abuse), but courts and DPAs disagree on whether that reaches 'strictly necessary' under ePrivacy. Declare it in the policy
• Gravatar - even in WordPress comments, Gravatar avatars leak user IP to Automattic. Declare or disable
• Live chat widgets (Intercom, Drift, Zendesk, Crisp, Tidio) - set persistent cookies whether or not the user opens the chat
• Calendly / scheduling widgets - set cookies the moment the embed loads
• Stripe / PayPal checkout - necessary but still must be disclosed. Stripe's fraud-prevention cookies can live for a year
• Cloudflare - strictly necessary (DDoS/bot protection) but appears on virtually every Cloudflare-fronted site; list it
• Social share buttons (AddThis, Sharethis, native Facebook/Twitter widgets) - tracking cookies even without interaction
• Embedded Twitter/X timelines or tweets - same
• Embedded Instagram feeds - cookies from Meta
• Analytics SDKs in mobile app WebViews - often bleed into the web domain

The generator pre-populates 62 services covering the above and more. Check every embedded third-party feature on your site and verify it's in the policy. For anything not in the preset list, use the custom cookie form.

Since March 2024, Google has required EEA-targeting advertisers to implement Consent Mode v2 for Google Ads, Google Analytics, and Google Tag Manager. Non-compliance means conversion data stops flowing and campaigns degrade. In practice, this applies to most sites running Google's marketing stack.

Consent Mode v2 works by passing four consent parameters to Google tags:

• ad_storage - can cookies be set for advertising?
• analytics_storage - can cookies be set for analytics?
• ad_user_data - can user data be sent for advertising?
• ad_personalization - can data be used for personalization?

When consent is granted, tags behave normally. When consent is denied, tags continue to fire but collect only aggregated, cookieless signals that Google uses for conversion modeling. The result: modeled conversion attribution that's significantly better than just blocking the tag, while still respecting the user's choice.

Implementation critical points:

• Set all four parameters to 'denied' by default, before any Google tag loads. This is the most common mistake - 67% of implementations default to 'granted' and fire tags before consent
• Use the wait_for_update parameter (500-1000ms) to give your CMP time to load actual consent state
• Update consent state immediately when the user interacts with the banner
• Basic mode (tag blocked until consent) or Advanced mode (cookieless signals before consent) - Basic is legally safer, Advanced has better modeling. Default to Basic unless your DPA has explicitly approved Advanced

The cookie policy should disclose Consent Mode v2 usage when enabled - that consent choices are passed to Google services, that denied consent triggers cookieless signal mode, and that no personal identifiers are collected when denied. The generator adds this disclosure when you enable the Consent Mode v2 toggle.

India's Digital Personal Data Protection Act, 2023 is the most populous data-protection regime in the world. Rules have been rolling out through 2025-2026, with Consent Manager registration opening November 2026.

Several DPDP requirements are unusual enough to matter for cookie policies:

• Consent must be free, informed, specific, clear, and unconditional
• Notice must be available in English plus any of 22 official Indian languages. Many sites ignore this
• Consent must be easy to withdraw, and withdrawal must be as easy as granting
• From November 2026, Consent Managers must register with the Data Protection Board of India. Only India-incorporated entities qualify. This excludes most foreign CMPs (Cookiebot, CookieYes, OneTrust) from acting as Consent Managers for DPDP purposes - they can still be vendors, but not Consent Managers
• Significant Data Fiduciaries (criteria based on volume, sensitivity, and risk) face enhanced obligations including Data Protection Officer appointment

In practical terms, if you have material Indian traffic, you need: localized multilingual banner (at least English plus Hindi for most national brands), an India-incorporated Consent Manager (or at minimum an Indian DPO for correspondence), and ready processes for data-subject requests in Indian languages.

The generator is enough when:

• You run a typical content site, SaaS, e-commerce, newsletter, agency, or app-with-website
• You use mainstream services (Google Analytics, Meta Pixel, Stripe, HubSpot, Cloudflare, YouTube)
• You operate in standard jurisdictions (EU, UK, US, Brazil, India)
• You've run a real cookie audit and the policy reflects reality
• You've tested your consent banner works (no pre-consent cookies, Accept/Reject equal, GPC honored)
• You review and update the policy every 6 months or when services change

Get a lawyer involved when:

• You're in a regulated industry - health data (HIPAA), children's services (COPPA, Age-Appropriate Design Code), financial services (GLBA, PSD2)
• You run real-time-bidding programmatic advertising and want to defend the legitimate-interest basis
• You operate in jurisdictions not covered by mainstream generators - China PIPL, Russia PDL, South Korea PIPA, UAE PDPL, Japan APPI with sensitive data
• You've had a prior DPA complaint or enforcement action and need to demonstrate remediation
• You're going through due diligence, fundraising, acquisition, or M&A - privacy disclosures are line-itemed
• You're becoming a Consent Manager in India or an IAB-registered CMP
• You're handling sensitive data categories (health, political opinions, sexual orientation, children's data) via cookies
• You've had users or regulators flag your banner as dark-pattern-y

A privacy attorney review typically costs $300-1,500 for 1-2 hours. At the scales where it matters, that's cheap insurance. Use the generator to produce the draft, then hand the draft to counsel for review - that's faster and cheaper than starting from a blank page.

Putting it all together, here's the workflow from zero to published cookie policy:

1. Use the Cookie Policy Generator to select your business model template. This pre-sets regional defaults and recommended services
2. Enter company details. Service name, legal name, address, privacy contact email, website URL, effective date
3. Select regions. Every region where you have actual traffic - EU, UK, California, other US states, Brazil, India
4. Run a cookie audit on your live site using DevTools (30 minutes). Write down every cookie
5. In the Cookies step, check every service that matches your audit. For cookies not in the preset list, use the custom cookie form
6. Configure consent mechanics: GPC, Do Not Track, TCF v2.3 (if programmatic ads), Consent Mode v2 (if Google marketing stack), layered notice, equal prominence, block-before-consent
7. Copy the banner variants from the Banner step and configure them in your CMP (Cookiebot, CookieYes, OneTrust) or DIY implementation. Test geolocation routing if applicable
8. Review the compliance scorecard in the Review step. Target 90%+ before publishing. Fix any failed checks
9. Export the HTML file from the Export step. Host it at /cookies/ or /cookie-policy/
10. Link to the policy from your site footer and from your consent banner
11. Cross-link with your Privacy Policy and Terms of Service
12. Export the JSON config to back up your configuration for future updates
13. Test everything: DevTools should show no non-essential cookies before consent on EU traffic; GPC should work on California traffic; Accept/Reject should be equally prominent; banner should be available in Portuguese for Brazilian traffic
14. Set a 6-month calendar reminder to re-audit and update

That's it. Cookie compliance isn't impossible - it's just tedious. The generator handles the tedious parts so you can focus on running your actual business.