Automated scanner — in rebuild
A trustworthy banner test has to open your site in a real browser and watch what loads before anyone clicks “Accept” — something a script running in your own browser can’t do safely across sites. We’re moving that check to a server-side scan.
In the meantime, use the compliance checklist below to audit your banner by hand, or the Consent Requirements Wizard to confirm what your banner legally must do.
What This Tester Checks
Most consent banner tools stop at asking “does a banner exist?” That misses the real compliance question: does the banner actually prevent tracking before the user consents? This consent banner checker loads your target URL in a real headless browser, intercepts every network request and cookie operation, then clicks the consent button and measures what changes. The gap between before and after consent is where most GDPR violations live.
Banner Present?
The tester scans the DOM for recognised consent management platform (CMP) signatures — OneTrust, Cookiebot, CookieYes, Complianz, iubenda, Quantcast, Didomi, TrustArc, CookieFirst, Osano, Usercentrics, Termly — as well as custom banners identified by common button-text patterns in English, German, French, Dutch, and Spanish. If no banner is detected on a page that sets non-essential cookies, that is flagged as a violation in itself.
Blocks Trackers Before Consent?
This is the check competitors skip. A banner that appears on screen but allows Google Analytics, Meta Pixel, or ad-network beacons to fire on first page load is not compliant, regardless of how it looks. The tester captures the full list of cookies set and third-party requests made before any interaction with the banner. Anything tracking-related that appears on that pre-consent list is a violation. The identity angle matters here: a tracker that fires before consent can resolve a returning visitor’s identity from a cookie set on a previous session — precisely the data collection that GDPR’s consent mechanism is designed to prevent.
Valid Reject Option?
Under the CJEU’s Planet49 ruling and subsequent regulatory guidance, withdrawing consent must be as easy as giving it. That means a “Reject All” button (or equivalent) must be at the same level of prominence as “Accept All” — not buried in a settings panel requiring three additional clicks. The tester checks whether a functional reject path exists at the top level of the banner and whether clicking it actually stops tracker execution.
Dark Pattern Detection
The tester flags the four dark patterns regulators have acted on most consistently: (1) pre-ticked consent boxes, (2) asymmetric button design where Accept is visually dominant and Reject is de-emphasised by color or size, (3) a “Manage Preferences” path that defaults all purposes to On, and (4) deceptive language such as “I agree to personalised ads” framed as the reject option. The European Data Protection Board’s 2022 dark patterns guidelines list all of these as unlawful nudging.
How to Use the Tester
- Enter a domain or full URL. The tester accepts bare domains (
example.com) or full URLs with paths. Testing a subpage is useful if your homepage has different tracking than your article or product pages. - Click “Test Banner”. The scan takes 20–30 seconds. A real headless Chrome instance loads the page, captures the pre-consent state, then locates and clicks the consent button.
- Read the Violations tab first. This lists every pre-consent tracker by name, category (analytics / advertising / functional), and the specific GDPR article it implicates.
- Check the Before vs After tab. This shows a side-by-side count of cookies and third-party requests before and after consent. A well-configured banner should show zero tracking cookies in the Before column.
- Export the report. The Markdown export gives you a timestamped evidence file you can share with a developer or include in a compliance audit record.
Need to determine what your banner legally requires based on your site’s audience, data residency, and cookie types? The Consent Requirements Wizard steps through the applicable law before you start configuring a CMP.
What GDPR Says a Valid Consent Banner Must Do
GDPR Article 7 and Recital 32 set the baseline: consent must be freely given, specific, informed, and unambiguous. Applied to a cookie banner, this translates to five operational requirements that regulators have consistently enforced.
| Requirement | What it means in practice |
|---|---|
| No pre-ticked boxes | Every consent purpose starts unchecked. The user must make an active, affirmative choice for each category. |
| Granular purposes | Consent for “analytics” is separate from “advertising.” Bundling all purposes into one Accept click violates the specificity requirement. |
| Equal reject path | Rejecting all non-essential cookies must require no more clicks than accepting them. |
| Scripts blocked until consent | Non-essential JavaScript must not execute before the user’s choice is recorded. This is the most commonly violated requirement. |
| Re-consent on material change | If you add new tracking purposes or partners, you must surface the banner again and collect fresh consent. |
The ePrivacy Directive (implemented as PECR in the UK and various national laws across the EU) adds a layer: even where GDPR consent requirements are met, the act of storing information on a user’s device requires prior consent unless the cookie is strictly necessary for a service explicitly requested by the user. Session cookies for a shopping cart qualify; a cookie that identifies a browser across sessions for analytics does not.
For a full breakdown of what GDPR consent legally requires — including the distinction between legitimate interest and consent, and when each applies — see our dedicated analysis.
Common Consent Banner Failures — and How to Fix Them
Failure 1: The banner is cosmetic, not functional
The most frequent failure mode: a banner appears on screen, the user accepts or rejects, but the tracking scripts were already loaded in the page’s <head> and fired milliseconds after the DOM was ready. The banner records a consent choice that came after the data had already been collected. Fix: Configure your CMP to use script-blocking mode. For tag managers, this means loading GTM itself only after consent, or using a consent-aware GTM configuration that sets all tags to require consent before firing. For directly embedded scripts, the CMP must change the script’s type attribute from text/javascript to text/plain until consent is given.
Failure 2: HTTP-header cookies set before JavaScript runs
Some tracking cookies are set server-side via Set-Cookie response headers, which means they are written to the browser before any JavaScript — including the CMP — can intercept them. This is common with legacy analytics implementations and ad-serving infrastructure. The consent banner checker catches these because it inspects the raw HTTP responses, not just the cookie jar after JavaScript has run. Fix: Move cookie-setting to client-side JavaScript so the CMP can gate it, or ensure your server conditionally sets tracking cookies only after reading a first-party consent signal from a previous session.
Failure 3: No “Reject All” at the top level
A banner that shows only “Accept All” and “Manage Preferences” forces users who want to reject tracking to navigate into a settings panel, find each toggle, and save. Regulators in France (CNIL), Germany (DSK), and Spain (AEPD) have all issued specific guidance that this is an unlawful dark pattern. Fix: Add a “Reject All” button at the same visual level as “Accept All.” Most major CMPs support this in their configuration — it is often disabled by default because it reduces consent rates.
Failure 4: Third-party iframes loading on page init
Embedded YouTube videos, social share widgets, and map embeds often create third-party cookies the moment the iframe src is resolved. If those iframes are present in the initial HTML with a live src attribute, they bypass the consent banner entirely. Fix: Use a facade pattern — render a static preview image with a click-to-load overlay, and only inject the actual iframe src after consent is granted for the relevant purpose.
If a violation is confirmed, you can use the GDPR Fine Calculator to estimate the fine for non-compliant consent based on annual turnover and the severity of the breach.
FAQ
What makes a consent banner legally valid?
A legally valid consent banner under GDPR must obtain freely given, specific, informed, and unambiguous consent before any non-essential cookies or trackers fire. In practice: no pre-ticked boxes, granular purpose categories, an equally prominent reject option, and verified script blocking before the user’s choice is recorded. The banner must also name the data controller and, where relevant under Article 49, list any third countries where data is transferred.
Do I need a “Reject All” button?
Yes, in most EU jurisdictions. The CJEU’s Planet49 judgment, the European Data Protection Board’s 2022 dark patterns guidance, and enforcement decisions from DPAs in France, Germany, Italy, and Spain all require that rejecting consent is no harder than accepting it. A banner with only “Accept” and “Manage Preferences” fails this standard. The UK ICO has issued equivalent guidance under PECR.
Can I pre-tick consent checkboxes?
No. GDPR Recital 32 explicitly states that pre-ticked checkboxes do not constitute valid consent. Consent requires an active, affirmative act. This applies to each individual purpose — you cannot pre-tick “Analytics” on the basis that the user can uncheck it. Any pre-consent data collection that results from pre-ticked boxes is collected without a lawful basis.
How do I test if my banner blocks trackers before consent?
Enter your domain in the consent banner checker above and run a scan. The tool loads your page in a real headless browser without clicking any button, records every cookie and third-party network request, then clicks your consent button and records what changes. Anything tracked in the pre-consent phase that is non-essential — analytics identifiers, advertising pixels, fingerprinting scripts — appears in the Violations tab with the specific script or cookie name.
Are dark patterns in consent banners illegal?
Yes. The European Data Protection Board published guidelines specifically on dark patterns in social media platforms in 2022, and DPAs have since applied the same standards to consent banners broadly. Asymmetric button design (a prominent “Accept” paired with a grey, smaller “Reject”), deceptive framing, and forced layering (burying rejection behind multiple screens) are all cited in enforcement decisions as rendering consent invalid because it is no longer freely given.
Do I need to show the consent banner on every page load?
No — once valid consent is obtained and recorded, you are not required to re-show the banner on every visit. However, you must show it again if: (a) the user’s prior consent record has expired (most DPAs treat 12 months as a reasonable maximum), (b) you have materially changed your data processing purposes or added new third-party processors, or (c) there is no valid consent record for the current browser (e.g., after cookie deletion). You must also provide an accessible mechanism for users to withdraw consent at any time, which most sites implement as a persistent “Cookie Settings” link in the footer.