Almost every modern website drops something onto a visitor's device — a session cookie, a localStorage entry, a tracking pixel, or a fingerprinting script. The moment you do that for anything beyond the bare minimum needed to deliver the page, you step into the territory of cookie law: GDPR, the ePrivacy Directive, the UK PECR, and an ever-growing list of similar regimes worldwide. This guide explains what cookies actually are, how regulators classify them, what your cookie policy must contain, and how to design a consent banner that is both compliant and respectful of your users.
This guide is informational, not legal advice. Consult a qualified attorney for your jurisdiction.
What Counts as a "Cookie"?
In everyday speech, "cookie" is shorthand for any client-side storage or identifier. The law agrees with that broad reading. The ePrivacy Directive does not single out HTTP cookies — it protects "information stored on the terminal equipment of a subscriber or user". That covers three overlapping technologies you should be aware of.
HTTP Cookies
The classic mechanism: small key-value strings set via the Set-Cookie header or document.cookie, scoped to a domain and path, with an expiry date and flags such as HttpOnly, Secure, and SameSite. Session cookies disappear when the browser closes; persistent cookies live until their expiry.
Web Storage (localStorage and sessionStorage)
A JavaScript API that lets a site stash arbitrary strings on the visitor's device. localStorage persists across sessions; sessionStorage is per-tab. Regulators treat these identically to cookies for consent purposes — if you are using them to remember a user or track behaviour, you need a lawful basis.
Fingerprinting and Other Identifiers
Device fingerprinting builds an identifier from properties such as screen size, installed fonts, canvas-rendering quirks, audio stack, and timezone. It writes nothing to the device, but it lets a server recognise the same browser on return visits. Because the user has no easy way to clear or refuse it, regulators have explicitly stated that fingerprinting requires consent — the technique cannot be used to side-step cookie law.
The Four Cookie Categories
Almost every consent platform organises cookies into four buckets. Knowing which is which is the foundation of compliant design.
1. Strictly Necessary
Cookies that are essential for a service the user has explicitly asked for: a logged-in session, a shopping basket, a CSRF anti-forgery token, a load-balancer routing cookie, or a cookie that remembers the user's consent choices. These do not require consent, but you must still disclose them.
2. Functional / Preferences
Cookies that remember non-essential choices — language, theme, video player volume, or a closed announcement bar. They improve the experience but the site works without them. Consent is required before they are set.
3. Analytics / Performance
Cookies set by Google Analytics, Plausible (if not in its cookie-less mode), Matomo, Hotjar, Microsoft Clarity, and similar tools. They measure traffic, behaviour, and errors. With a narrow exception for first-party, aggregated, properly anonymised analytics in some jurisdictions, these require prior consent.
4. Advertising / Targeting
The Meta pixel, Google Ads remarketing tags, LinkedIn Insight, TikTok pixel, programmatic SSP scripts, affiliate trackers, and anything else that builds an audience or attributes a conversion. These always require explicit, granular, opt-in consent.
What "Valid Consent" Actually Means
Article 4(11) and Article 7 of the GDPR, read alongside the ePrivacy Directive, define consent as a "freely given, specific, informed and unambiguous indication" of agreement. Regulators have translated that into five operational tests your banner must pass.
- Prior: No non-essential cookies, pixels, or fingerprinting scripts may fire before the user clicks Accept. Tag managers must be configured to wait for the consent signal.
- Granular: Users must be able to accept analytics while refusing advertising, or vice versa. A single "Accept all our partners" toggle is not granular.
- Freely given: Access to the site cannot be conditional on accepting non-essential cookies, except where a clearly disclosed "pay-or-consent" model is offered and meets local regulator guidance.
- Informed: Before clicking, users must be able to see who the controllers are, what data is collected, and where to find the full cookie policy.
- Withdrawable: Withdrawing consent must be as easy as giving it — usually a persistent floating button, a footer link, or a dedicated cookie-settings page.
What a Cookie Policy Must List
The policy is the long-form document linked from the banner. For every cookie or local-storage entry you set, regulators expect you to disclose:
- Name: The exact cookie or storage key (for example
_ga,__Secure-3PSID,fbp). - Provider: The domain that sets it — your own, or a named third party such as
google-analytics.comorconnect.facebook.net. - Purpose: A plain-language description: "Distinguishes users for Google Analytics", not "Analytics".
- Category: Strictly necessary, functional, analytics, or advertising.
- Duration: The lifetime — "Session", "13 months", "2 years". Persistent cookies should generally not exceed 13 months for advertising and 25 months for analytics under recent EDPB guidance.
- Third-party transfers: Whether the cookie causes data to be sent to a third country, which one, and the safeguard relied on (for example the EU–US Data Privacy Framework or Standard Contractual Clauses).
A clean HTML table that you regenerate from an automated scanner is far easier to maintain than a prose paragraph.
Designing a Compliant Banner
The visual design is where most sites fail their audits. Use these rules as a checklist.
Parity Between Accept and Reject
Accept All and Reject All must appear on the same layer, with buttons of identical size, contrast, and colour weight. A bright Accept button next to a greyed-out Reject link is the textbook example of a dark pattern.
No Pre-Ticked Boxes
The Court of Justice of the European Union settled this in the Planet49 case: a pre-ticked box is not consent. Every non-essential category must default to off.
No Implicit Consent
Scrolling, continuing to browse, or closing the banner with a corner X must not be interpreted as acceptance. The user must take a positive action on a clearly labelled control.
Three Layers of Information
Layer one is the banner itself, with a short summary and three buttons (Accept, Reject, Settings). Layer two is the settings modal, with one toggle per category and a list of named vendors. Layer three is the full cookie policy page.
A Persistent Way to Revisit
Provide a floating "Cookie settings" button, or a footer link that opens the settings modal. Users who change their mind must not have to hunt.
Google Consent Mode v2 in Plain English
Since March 2024, Google requires sites that advertise to or measure users in the EEA, UK, or Switzerland to send two extra consent signals alongside the existing four: ad_user_data and ad_personalization. Together they tell Google whether it may use the visitor's data to build advertising audiences and whether it may personalise the ads shown.
Consent Mode operates in two flavours. Basic mode blocks all Google tags entirely until consent is given — the simplest and safest implementation. Advanced mode lets the tags load in a cookieless, identifier-free state when consent is refused, sending pings that Google then uses for modelled conversions. Advanced delivers better reporting, but you must disclose the cookieless pings in your policy and confirm with your data-protection officer that they are acceptable.
Implementation is usually done through Google Tag Manager: a Consent Initialisation trigger sets the default state to denied, and an event from your consent banner updates the state when the user makes a choice.
Common Pitfalls to Avoid
- Loading analytics before consent. Audit your
<head>— if Google Analytics, Hotjar, or a Meta pixel fires on first paint, the banner is decorative and the site is non-compliant. - A hidden "legitimate interest" toggle. Some IAB TCF banners ship with a second tab that pre-enables vendors under legitimate interest. Regulators have repeatedly ruled this invalid for cookies and tracking. Disable that tab.
- No settings page. Once consent is given, there must be a way to change it without clearing browser storage. A footer link is the minimum.
- Inconsistent geographic logic. Showing the banner only to EU IPs is fine, but make sure UK, Swiss, Brazilian (LGPD), and increasingly Indian (DPDP) and US state visitors are also covered by the rules that apply to them.
- Consent records you cannot produce. You must be able to show, on request, when a specific user consented, to which categories, and from which banner version. Store an anonymised consent log.
- Banner blocks accessibility. The banner must be keyboard-navigable, screen-reader friendly, and must not trap focus. WCAG 2.2 AA is the working standard.
- Forgetting embedded content. YouTube iframes, Vimeo players, Twitter timelines, and Google Maps all set cookies. Wrap them in click-to-load placeholders that only load after consent.
Putting It All Together
A defensible cookie programme has four moving parts: an automated scanner that inventories every cookie and storage entry across your site, a consent-management platform (CMP) that renders the banner and stores the audit trail, a tag manager configured to gate non-essential tags on the CMP signal, and a cookie policy page that is regenerated from the scanner output. Wire those together, run a quarterly review, and document the date of each change. That is what a regulator will ask to see.
Cookies are not going away — even as third-party cookies fade, first-party identifiers, server-side tagging, and on-device storage are growing. The legal duty to be transparent and ask before tracking is here to stay. Treat consent as a product feature, not a compliance afterthought, and your visitors will reward you with the trust that makes the rest of your site worth visiting.