GDPR Consent Banner: Requirements and How to Implement One

The legal basis

Why You Need a Consent Banner

The requirement for a cookie consent banner stems from two interlocking pieces of European legislation: the ePrivacy Directive (Directive 2002/58/EC, as amended by Directive 2009/136/EC) and the General Data Protection Regulation (Regulation 2016/679). The ePrivacy Directive — often called the “Cookie Law” — establishes the foundational rule: storing or accessing information on a user’s device requires informed consent, unless that storage is strictly necessary for a service the user explicitly requested. The GDPR then defines what valid consent looks like and imposes the enforcement framework that gives the rule teeth.

Together, these regulations mean that any website setting non-essential cookies — analytics, advertising, social media embeds, session recordings, A/B testing, retargeting pixels — must obtain informed, unambiguous, freely given consent from the user before those cookies are placed. A consent banner is the standard mechanism for collecting that consent. It is how you present the choice, explain what you are asking for, and record the user’s decision.

Without a compliant consent banner, your website is almost certainly violating the law. The scale of non-compliance is enormous — studies consistently find that over 90% of websites either have no consent mechanism at all, or have one that fails to meet the legal requirements. But regulators are no longer turning a blind eye. The French CNIL fined Google €150 million and Facebook €60 million specifically for making cookie rejection harder than cookie acceptance. The Italian Garante has issued guidelines requiring “reject all” buttons to be as prominent as “accept all.” The Austrian DSB triggered the landmark Schrems ruling on Google Analytics by acting on a single individual’s complaint about cookie consent. Enforcement is increasing, complaints are easy to file, and automated scanning tools make violations trivially detectable.

The bottom line is simple: if your website uses any non-essential cookies or tracking technologies, you need a consent banner. Not a notification banner, not an informational popup, not a “we use cookies” acknowledgment — a genuine consent mechanism that gives users a real choice and respects that choice technically by blocking scripts until consent is given.

What the law requires

Legal Requirements for a Valid Consent Banner

The requirements for a valid consent banner are drawn from GDPR Article 7 (conditions for consent), GDPR Recitals 32 and 42, the European Data Protection Board’s Guidelines 05/2020 on consent, and enforcement decisions from national data protection authorities across the EU. While individual DPAs may emphasize certain points differently, the core requirements are consistent and well-established. Here is what your banner must do to be legally compliant.

1. Appear before non-essential cookies are set. This is the most fundamental requirement and the most commonly violated. No analytics scripts, advertising pixels, social media trackers, or other non-essential technologies may load until the user has affirmatively consented to the relevant category. This is known as “prior blocking” or “prior consent.” A banner that displays while cookies are already being set is not collecting consent — it is providing a notification, which is legally insufficient.
2. Clearly explain what cookies are used and why. Consent must be informed. Users cannot meaningfully consent to something they do not understand. Your banner must explain, in plain language, the categories of cookies your site uses and the purpose of each category. Vague statements like “we use cookies to improve your experience” do not meet this standard. You need to distinguish between analytics cookies, advertising cookies, functional cookies, and any other categories relevant to your site.
3. Offer Accept and Reject options with equal prominence. The EDPB has explicitly stated that refusing consent must be as easy as giving it. This means your “Reject All” or “Decline” button must be just as visible, just as accessible, and presented at the same level of the user interface as your “Accept All” button. Hiding the reject option behind a “Manage Preferences” link, making it smaller, using a less contrasting color, or requiring extra clicks to reach it are all violations. The CNIL’s €150 million fine against Google was precisely about this point.
4. Allow granular, category-level control. Consent must be specific. Users must be able to accept some categories of cookies while rejecting others. A banner that only offers “Accept All” or “Reject All” without the option to customize by category does not meet the specificity requirement. At minimum, you should provide toggles for analytics, advertising/marketing, and functional cookies. Strictly necessary cookies do not require consent and should not be toggleable.
5. Not use pre-ticked boxes or default-on toggles. GDPR Recital 32 is explicit: silence, pre-ticked boxes, and inactivity do not constitute consent. If your banner shows cookie category toggles, they must be off by default. The user must actively turn them on. The Court of Justice of the European Union confirmed this in the Planet49 judgment (Case C-673/17), ruling that pre-checked consent checkboxes are invalid under both the ePrivacy Directive and the GDPR.
6. Store proof of consent. Article 7(1) of the GDPR states that “where processing is based on consent, the controller shall be able to demonstrate that the data subject has consented.” You must record what the user consented to, when they consented, what information was presented to them at the time, and the version of your consent mechanism that was displayed. If a regulator or data subject challenges your consent practices, you need to be able to produce this evidence.
7. Allow users to withdraw consent easily. Article 7(3) requires that withdrawing consent must be as easy as giving it. Your website must provide a persistent, easily accessible way for users to change their consent preferences after the initial decision. This is typically a small floating button, a link in the footer, or an icon that reopens the consent preferences panel. If a user accepted cookies on Monday and wants to withdraw consent on Wednesday, the process should require no more effort than the original acceptance did.
8. Not block access to the site with a cookie wall. A cookie wall is a banner that prevents the user from accessing any content until they accept cookies. The EDPB has stated in Guidelines 05/2020 that cookie walls generally do not meet the “freely given” requirement of consent, because the user has no genuine choice if the alternative to accepting cookies is being denied access entirely. While some national DPAs (notably the Dutch AP) have carved out limited exceptions, the prevailing guidance across Europe is that cookie walls are non-compliant. Your banner should allow users to reject all non-essential cookies and still access your website fully.

Practical checklist

What to Include in Your Consent Banner

Translating the legal requirements into a concrete implementation means including specific elements in your banner. Use the following as a design and development checklist. Every compliant consent banner should include all of these elements.

A well-designed banner balances legal completeness with user experience. The first layer (the initial banner) should be concise — users should be able to make a basic choice (accept, reject, or customize) within seconds. The second layer (the preferences panel) provides the granularity and detail that the law requires. This two-layer approach has become the de facto standard and is explicitly endorsed by most European DPAs.

One additional consideration: language. Your consent banner must be presented in the language of your target audience. If you serve users in multiple countries, the banner should detect the user’s language preference and display accordingly. A French user visiting your German e-commerce site should see the banner in French (or at least in English as a common fallback). Presenting a consent mechanism in a language the user does not understand undermines the “informed” component of valid consent.

Common violations

What NOT to Do: Mistakes That Get Sites Fined

Understanding the requirements is one thing. Knowing the specific patterns that regulators flag and fine is equally important. The following practices are drawn from actual enforcement actions, EDPB guidance, and audit findings across European data protection authorities. Every one of these has resulted in regulatory action against real websites.

These are not edge cases or technicalities. They are the patterns that data protection authorities look for first, because they are the easiest to detect and the most clearly documented as violations. Automated compliance scanners (including FixGDPR’s) can identify most of these issues in seconds. If a scanner can find them, a regulator can too — and so can any user who decides to file a complaint.

UX considerations

Placement and Timing

Beyond legal compliance, the placement and timing of your consent banner have significant implications for user experience, accessibility, and your website’s Core Web Vitals performance scores. Getting these elements right ensures that your banner is both compliant and respectful of the people visiting your site.

When should the banner appear? The banner must appear on the user’s first visit to your site, before any non-essential cookies are set. It should render as part of the initial page load — not after a delay, not after scrolling, and not triggered by a JavaScript timeout. Delayed banners create a window during which cookies could be set without consent, and they also create a jarring experience when the banner suddenly appears mid-read. Load the banner immediately, synchronously with the page, so the user sees it before interacting with any content.

The banner should not delay page load. A consent banner that adds 500ms or more to your page’s Largest Contentful Paint (LCP) or introduces Cumulative Layout Shift (CLS) is actively harming your site’s performance and search rankings. The banner’s HTML and CSS should be lightweight. Any JavaScript logic for managing consent preferences should be loaded asynchronously or deferred. If you are using a third-party consent management platform, check its impact on your Core Web Vitals — some popular CMPs add over 200KB of JavaScript and create noticeable layout shifts. This is unacceptable.

Accessibility is not optional. Your consent banner is arguably the most critical interactive element on your site, since it governs privacy choices for every visitor. It must be fully keyboard navigable, with clear focus indicators. It must work with screen readers, using proper ARIA attributes, semantic HTML, and meaningful button labels. Color contrast must meet WCAG AA standards at minimum. If your banner fails accessibility requirements, it is not just poor practice — it may mean that users with disabilities cannot exercise their privacy rights, which is a compliance issue in itself.

Mobile responsiveness matters. A banner that works beautifully on desktop but covers the entire viewport on a mobile device, with tiny touch targets and cramped text, is a problem. Design your banner with mobile as the primary constraint. Buttons should have adequate touch target sizes (at least 44x44 CSS pixels per WCAG guidelines). The banner should not cover essential content or navigation. Test on real devices across common screen sizes.

Do not cover essential content. A full-viewport modal that obscures the page content and forces interaction before reading is uncomfortably close to a cookie wall. The preferred approach is a bottom-anchored or top-anchored bar that leaves the majority of the page content visible and accessible. The user should be able to see what the site is about before making a consent decision. If your banner is so large that the user cannot see anything behind it, reconsider your design.

Technical implementation

Consent Storage: Recording and Proving Consent

Collecting consent is only half the obligation. Article 7(1) of the GDPR requires that you be able to demonstrate that consent was obtained. This means you need a robust system for recording, storing, and retrieving consent records. If a data protection authority audits your site or a user disputes whether they consented, you must be able to produce evidence.

A compliant consent storage implementation typically involves two components working together: a client-side cookie that stores the user’s current consent state for immediate use by your website, and a server-side consent record that provides a durable, tamper-resistant log of consent events for audit purposes.

What to record

Every consent event — whether the user accepts, rejects, or customizes their preferences — should be logged with the following information:

The client-side cookie is a first-party cookie (typically with a 6–12 month expiry) that your website reads on each page load to determine which scripts to activate. This cookie itself is classified as “strictly necessary” because it is required to honor the user’s privacy preferences — it does not require consent. The server-side record is what you produce in an audit. It should be stored in a way that prevents retroactive modification — ideally in an append-only log or a system with immutable records.

If your consent management platform handles all of this automatically, verify that it does. Many lightweight or DIY consent solutions store the preference in a cookie but fail to maintain a server-side audit trail. That leaves you unable to demonstrate consent if challenged, which is a compliance gap.

Important distinction

Consent Banner vs. Cookie Wall

A consent banner and a cookie wall may look similar at first glance, but they are fundamentally different mechanisms with very different legal standing. Understanding the distinction is critical, because building a cookie wall when you intended to build a consent banner is a mistake that can result in enforcement action.

A consent banner is an overlay, bar, or panel that presents the user with a genuine choice about cookies and tracking technologies. Crucially, the user can decline all non-essential cookies and still access the full website and its content. The banner is an information and choice mechanism — it informs the user, offers options, records the decision, and then gets out of the way, regardless of which option the user chose.

A cookie wall is a barrier that blocks access to the website’s content until the user accepts cookies. In a cookie wall implementation, declining cookies means you cannot read the article, use the service, or access the page. The user is presented with what appears to be a choice, but the only option that actually grants access is “Accept.” This is not a genuine choice — it is a coercive mechanism that conditions access on consent.

The EDPB addressed this directly in Guidelines 05/2020 on consent, stating: “Access to services and functionalities must not be made conditional on the consent of a user to the storing of information, or gaining of access to information already stored, in the terminal equipment of a user (so called cookie walls).” The rationale is straightforward: if the only way to access a website is to accept all cookies, then consent is not freely given, because the user has no real alternative.

There are limited exceptions that some national DPAs have recognized. The Dutch Data Protection Authority (Autoriteit Persoonsgegevens) has indicated that a cookie wall may be permissible if the publisher offers an equivalent alternative means of accessing the content without cookies — for example, a paid subscription option. The French CNIL has taken a similar position in narrow circumstances. However, these exceptions are not universal, they are fact-specific, and relying on them carries significant risk. The safest and most broadly compliant approach is to avoid cookie walls entirely.

Step-by-step

Implementation with FixGDPR

Building a fully compliant consent banner from scratch is possible, but it requires significant engineering effort: script blocking logic, preference storage, audit logging, UI design that meets both legal and accessibility requirements, Google Consent Mode integration, and ongoing maintenance as regulations evolve. FixGDPR handles all of this with a single script tag, so you can be compliant in minutes rather than months. Here is how it works.

1. 1

   Sign up for FixGDPR

   Create your FixGDPR account. The free tier includes a full compliance scan and access to the consent banner for one site. No credit card required. You will have a working banner before you finish your coffee.

2. 2

   Add your site

   Enter your website’s URL in the FixGDPR dashboard. Our scanner runs an initial audit of your site, detecting all cookies, third-party scripts, and tracking technologies. We automatically categorize everything we find into the standard GDPR consent categories: strictly necessary, analytics, marketing, and functional. You can review and adjust the categorization before going live.

3. 3

   Add one script tag (or install the WordPress plugin)

   Copy a single <script> tag from your dashboard and paste it into the <head> section of your website. If you use WordPress, install our dedicated plugin instead — no code editing required, no theme modifications, just activate and configure from the WordPress admin panel. Either way, the integration takes under two minutes.

   <!-- Add this to your <head> section -->
   <script src="https://cdn.fixgdpr.com/v1/consent.js"
     data-site-id="your-site-id"
     async></script>
4. 4

   The banner handles everything automatically

   Once the script is installed, FixGDPR’s consent banner automatically appears for new visitors. It blocks non-essential scripts by default and only activates them when the user consents to the corresponding category. Accept All, Reject All, and Manage Preferences are all presented on the first layer with equal prominence. Consent preferences are stored client-side for immediate script-blocking decisions and server-side for audit-ready proof of consent. When a user returns to your site, their previous consent state is restored without re-showing the banner.

5. 5

   Google Consent Mode v2 included

   FixGDPR’s banner natively integrates with Google Consent Mode v2, the framework Google now requires for any site using Google Ads, Google Analytics, or other Google marketing products in the EEA. Consent signals are automatically communicated to Google tags, enabling cookieless conversion modeling and behavioral modeling for users who decline tracking. This means you maintain advertising measurement capabilities while fully respecting user consent. No additional configuration is needed — Consent Mode v2 support is enabled by default.

6. 6

   Under 20KB, no Core Web Vitals impact

   The FixGDPR consent script is under 20KB gzipped — a fraction of the size of most consent management platforms, which often ship 150–300KB of JavaScript. We add no Cumulative Layout Shift and negligible impact to Largest Contentful Paint and Interaction to Next Paint. Your PageSpeed score and search rankings will not suffer. We benchmark every release against Core Web Vitals thresholds and maintain a strict performance budget.