How to Test a Cookie Consent Banner

Last reviewed: 29 August 2026

The browser can establish technical facts: which requests were made, what was stored, which controls were reachable, and whether behavior changed after a choice. Those facts are not, by themselves, a legal conclusion. Whether a technology is strictly necessary, whether consent is required, and whether the wording is adequate depend on purpose, jurisdiction, and the full processing arrangement.

Automated scanners are useful for discovery and repeatable monitoring, but they cannot reproduce every interaction or prove compliance. Treat scan results as one input, retain a dated test record, and rerun the matrix whenever tags, templates, plugins, embeds, or consent settings change.

What a cookie banner test should prove

A good test answers two separate questions.

Technical verification establishes what loads before a choice, which storage and requests appear, whether categories control their intended tools, whether withdrawal changes future behavior, and whether controls work across pages, devices, and input methods.

Legal review assesses whether consent is required, an exception applies, the choice is valid, refusal and withdrawal are presented appropriately, and notices, purposes, vendors, retention, records, and downstream processing are adequate.

The ePrivacy Directive's Article 5(3) provides the EU baseline for storing information on, or accessing information from, a user's device. It generally requires information and consent, subject to its transmission and strictly-necessary exceptions. EU countries implement that rule nationally. GDPR can also apply where personal data is processed and sets conditions for consent, including the ability to withdraw it.

That is why this checklist uses observed, expected, and investigate, rather than awarding a “compliance score.” A clean network trace can support a legal review; it cannot replace one. For the wider framework, read what the ePrivacy Directive means for cookies.

Prepare a repeatable cookie consent test

Testing is useful only when another person can reproduce it. Define the environment, routes, actions, and expected outcomes before opening the site.

Choose representative routes and interactions

Include at least one page from every materially different template: the homepage; a product or service page; content with sharing tools; a form; an account, cart, or checkout route; a page with video, maps, chat, reviews, or social content; and a campaign landing page.

List the interactions that may load additional services: playing a video, opening chat, submitting a form, expanding a map, signing in, adding an item to a basket, or moving between client-side routes. An initial page load cannot expose code that runs only after one of these actions.

Record the environment

For each run, note the date and release, URLs and route sequence, region and language, browser and operating system, device or viewport, profile mode, login state, extensions and privacy settings, consent choice, and expected versus observed result.

Geolocation, A/B tests, browser privacy protections, and logged-in state can change both the banner and third-party behavior. A failure seen in one environment may not reproduce in another unless those conditions are recorded.

Start genuinely clean

Use a new browser profile where possible. A private window is convenient, but first confirm all private windows for that browser are closed, because some browsers share the same temporary session between private windows.

Before each scenario:

1. Open DevTools.
2. Clear cookies and site data for the tested origin and relevant subdomains.
3. Clear local storage, session storage, IndexedDB, and service-worker or cache data where applicable.
4. Disable extensions unless an extension is deliberately part of the test.
5. Open the Network panel, enable recording, and enable Preserve log.
6. Disable the network cache while DevTools is open if you need a complete request trace.
7. Navigate from a blank tab to the test URL.

In Chromium DevTools, storage appears under Application; Firefox provides a Storage Inspector. document.cookie is not a complete inventory because JavaScript cannot read HttpOnly cookies. Use the browser's storage tools and response headers instead.

Build the core consent-state matrix

Run every row independently from a clean state unless the row specifically tests a return visit. This avoids a previous preference, cached resource, or identifier changing the result.

State	Starting condition	Visitor action	Verify in interface	Verify in storage and network
Clean load	No site data	Load page; make no choice	Banner appears as configured; page remains usable as intended	Capture initial cookies, all storage, response headers, requests, and consent defaults
No choice	Clean load	Browse representative routes without choosing	Banner state is consistent; settings remain available	Optional categories do not activate merely because of navigation or time
Accept all	Clean load	Select Accept all	Choice is acknowledged and can be revisited	Intended categories activate; consent preference is saved; unexpected tools do not appear
Reject non-essential	Clean load	Select Reject or equivalent	Refusal is available and remembered	Optional categories stay inactive; compare requests and storage with the clean baseline
Granular	Clean load	Enable one optional category and disable others	Saved controls match the chosen combination	Only tools mapped to the enabled category activate
Change choice	Prior saved choice	Reopen settings; turn a category off or on	Updated choice is shown and retained	Future activity follows the new choice; storage and signals update
Revisit	Saved choice in a new page/session	Reload, navigate, then return later	Correct preference is restored until the configured renewal event	No transient optional activity occurs before the saved choice is read

Do not reduce the result to “cookies present” or “cookies absent.” Record cookie names, domains, expiry and relevant attributes, other storage, request URLs, initiators, status, and Set-Cookie headers. Redact live identifiers from broadly shared evidence.

Step 1: Test the clean and no-choice states

This is the most important baseline because a banner cannot retroactively prevent storage or access that already happened.

Capture storage before interaction

Load the page and do not click, scroll, or wait through an artificial delay unless those actions are separate test cases. Inspect:

• first-party and third-party cookies;
• local storage and session storage;
• IndexedDB databases;
• Cache Storage and active service workers where relevant; and
• cookie-setting response headers.

Do not declare every unfamiliar first-party cookie “necessary.” First-party describes context, not purpose. Analytics and advertising services can set first-party identifiers. Trace each item to its script or response and compare its purpose with the site's documented classification.

Likewise, a consent-preference cookie appearing before a choice is not automatically an error; it may store a neutral state. Verify what it contains, why it is needed, and whether it triggers anything optional.

Inspect the initial request chain

Reload with network recording active. Filter by known vendors, but also review the unfiltered domain list and initiators. A tracker may use a proxy or first-party endpoint, so searching only for familiar cookie names such as _ga or _fbp is insufficient.

Pay attention to hard-coded scripts, tag-manager launches, redirects and iframe requests, server-side tagging endpoints on first-party subdomains, and requests made after timers, scrolling, or route changes.

A request to a third party is a technical observation, not automatic proof of unlawful tracking. It might fetch a required resource without setting or reading an identifier. Conversely, no new cookie does not prove no device information was accessed or no personal data was sent. Investigate the request's purpose, parameters, response, and applicable rule.

If optional tools run too early, use the guide to blocking cookies before consent to trace hard-coded scripts, tag-manager triggers, and injected plugins.

Step 2: Test accept, reject, and granular choices

The banner's visual response and the site's technical response must agree.

Verify accept all

From a clean state, record the exact button selected and timestamp, then accept all. Navigate through the test routes and perform the defined interactions.

Compare the trace with the no-choice baseline. Intended optional tools may now initialize, but unrelated or undocumented services should not appear. Confirm that storage and reopened settings represent the choice. An analytics visit alone does not establish correct category control.

Verify reject non-essential

Start clean again and refuse optional categories. Browse, reload, and trigger the same page interactions used for acceptance. Inspect storage and requests throughout.

Watch for a closing banner while tags still fire, an embed loading too early, deleted cookies but continuing collection requests, uncontrolled campaign templates, failures after client-side navigation, or consent signals that update after measurement began.

Browser privacy features can hide a defect. If a browser blocks a third-party cookie independently, the absence of that cookie does not prove the banner controlled the service. The request log and initiator chain help distinguish CMP behavior from browser intervention.

Verify granular categories one at a time

Test each optional category separately. For example:

1. enable analytics and leave advertising off;
2. enable advertising and leave analytics off;
3. enable preferences while leaving both off; and
4. test any vendor-level controls your banner offers.

For each combination, reload and revisit settings. Confirm that saved state remains and only mapped services activate. Whether categories are sufficiently specific is a legal and design question; this test establishes whether they control declared tools.

Step 3: Test changing, withdrawing, and revisiting consent

GDPR Article 7(3) says withdrawal must be as easy as giving consent. Browser testing can measure the actual interaction and resulting behavior; legal review determines whether that implementation meets the applicable standard.

Change an existing choice

Accept optional categories, reopen preferences using the visible settings control, and turn one category off. Record its location, keyboard and touch access, steps required, displayed prior state, persistence after reload, and effects on future requests, tags, and identifiers.

Turning a category off should prevent future activity controlled by that choice. Existing cookies do not always disappear automatically; whether they should be deleted, retained for a limited purpose, or handled another way requires tool-specific and legal analysis. At minimum, document actual behavior rather than assuming that updating a consent cookie cleans up every vendor identifier.

Repeat in the opposite direction: reject first, then enable one category. Check that the newly permitted service starts only after the update.

Test a return visit and renewal

Close the tab, reopen the site, navigate directly to a deep link, and start a new browser session while preserving site data. The site should read the saved preference before optional tools make decisions. Look for a race in which tags briefly load before the CMP restores state.

Test defined renewal events such as preference expiry, a banner-version change, a new purpose or vendor, and any configured re-consent interval. Browser updates and private mode do not universally require renewed consent. Policy and applicable law should define when a new choice is needed.

Step 4: Test embeds and delayed trackers

Video, maps, social posts, chat, reviews, forms, and payment components often behave differently from global tags.

For each embed, test three moments:

1. page load before a choice;
2. after rejecting its category; and
3. after enabling its category or deliberately requesting the feature.

Inspect iframe creation, network connections, cookies, local storage, and scripts. A thumbnail served locally may be different from an iframe that connects to the provider immediately. If the site uses a click-to-load placeholder, verify that it explains the consequence, works with keyboard and touch, and loads the provider only at the intended point.

Then repeat after client-side navigation. Single-page applications can mount a component without a full reload and bypass logic that worked on the initial document.

Step 5: Verify Google Tag Manager and Consent Mode

Google's Consent Mode is a mechanism for communicating consent states to Google tags. It does not collect consent, classify technologies, or decide whether your implementation is lawful.

Check defaults before Google measurement commands

Use Tag Assistant to connect to the site and inspect the consent events for the initial page. For implementations that use these types, review:

• analytics_storage;
• ad_storage;
• ad_user_data; and
• ad_personalization.

Google's documentation says consent defaults should be set before commands that send measurement data, and updates should be sent on the page where the choice occurs before navigation. Confirm ordering in the event timeline rather than checking only the final state.

The expected default depends on the implementation and region configuration. Where your policy requires prior permission, relevant optional consent types should not begin as granted. Record the expected state per region and compare it with Tag Assistant.

Test every update path

Run clean, accept, reject, granular, withdrawal, and revisit scenarios. Verify that:

• the initial default event appears before affected tags;
• the update event reflects the exact category choice;
• analytics-only consent does not grant advertising consent;
• rejection and withdrawal produce the intended denied states;
• the saved state is restored correctly on later pages; and
• GTM tags have appropriate built-in or additional consent checks.

Use GTM's Consent Overview to inspect tag configuration, but do not treat the overview as runtime proof. Tag Assistant's event sequence and the browser's storage and network panels show what happened on the tested page.

Distinguish basic and advanced Consent Mode

In Google's basic implementation, Google tags are blocked until the visitor interacts with the banner. In advanced Consent Mode, Google tags load with defaults and can send cookieless pings when consent is denied. Therefore, “no Google network request after rejection” is not a valid universal pass criterion.

Instead, establish which implementation the site intentionally uses. Then verify consent states, cookie behavior, request parameters, tag ordering, and documented configuration. A denied state is not the same as no request, and a cookieless ping is not itself a legal approval. Whether the chosen mode and data flow are appropriate requires a separate jurisdiction-specific assessment.

Step 6: Test mobile and accessibility behavior

A technically correct desktop banner can fail on a small screen or be unusable with assistive technology.

Mobile checks

Test a real mobile browser where possible, in portrait, landscape, and a narrow viewport. Check that choices remain visible without horizontal scrolling; text zoom and the on-screen keyboard do not hide controls; touch controls are spaced; long panels scroll; closing restores sensible focus; and rotation does not reset or break the dialog.

Also test slower network conditions. A late-loading CMP must not allow optional tags to win a race during startup.

Keyboard and screen-reader checks

Without using a mouse:

1. Tab through the page from the address bar.
2. Confirm focus reaches the banner and all choices in a logical order.
3. Activate buttons and toggles with the expected keyboard controls.
4. Open and close the detailed panel.
5. Confirm focus is visible and does not become trapped or lost.
6. Confirm Escape behavior is intentional and does not silently imply consent.
7. Reopen settings from the permanent control.

With a screen reader, check that the banner or dialog has an accessible name, headings are meaningful, button names communicate their actions, toggle states are announced, and changed status is perceivable. Inspecting ARIA attributes helps, but actual keyboard and assistive-technology use is necessary because valid markup can still produce an unusable flow.

WCAG is an accessibility standard, not a cookie-consent law or automatic legal verdict. Use its success criteria to test perceivability, operation, focus, labels, and reflow, then obtain accessibility and legal review appropriate to the service.

Step 7: Turn the matrix into regression tests

Keep a small manual suite for judgment-heavy interface checks and automate stable technical assertions.

Good candidates for automation

In a controlled environment, browser automation can create fresh contexts, visit defined routes, select controls by accessible role and name, capture storage and requests, assert category state after reload, compare consent-state traces, and retain failure artifacts.

Assertions should reflect your documented implementation, not a generic blacklist copied from another site. Vendor domains and cookie names change, and first-party proxies can make domain-only rules misleading. Prefer positive ownership: maintain an approved service inventory, expected category, trigger, and allowed state for each service.

Do not run automated tests against production in a way that creates real leads, purchases, advertising conversions, or personal data. Use test accounts, non-production endpoints, and vendor debug modes where available.

Keep essential manual checks

Humans should still review clarity, visual balance, mobile usability, keyboard flow, screen-reader announcements, translated text, policy links, and whether categories make sense. Automation can tell you that a button exists; it cannot reliably decide whether the overall choice is informed or non-manipulative.

Run the suite after changes to:

• CMP configuration or banner copy;
• GTM containers and server-side tagging;
• themes, templates, plugins, apps, or SDKs;
• analytics, advertising, experimentation, or personalization tools;
• video, maps, chat, forms, or social embeds; and
• routing, caching, localization, or regional targeting.

A scheduled review is also useful, but it is not a legal safe harbour. Change-triggered testing catches drift sooner.

How scanners fit into the process

A scanner can crawl more routes than a quick manual session and provide a repeatable inventory of cookies, storage, or requests it observes. Run the ConsentEase cookie scanner or another suitable tool before and after remediation, then reconcile the output with DevTools.

Scanners may miss authenticated or conditional routes, interactions, regional variants, granular combinations, and services behind first-party proxies. They cannot determine strict necessity or whether consent and information satisfy every applicable law.

An empty scan is not proof that nothing happens, and a flagged request is not proof of a violation. Investigate discrepancies. Our step-by-step website cookie audit explains how to build the underlying inventory.

Document results without claiming a compliance score

For every scenario, retain:

• environment and starting state;
• steps performed;
• expected result;
• observed interface state;
• cookies and other storage observed;
• material requests and their initiators;
• Consent Mode event order, if used;
• pass, fail, or investigate status;
• owner, remediation, and retest date; and
• links to the applicable internal requirement and legal review.

Use “pass” to mean that an implementation met a defined technical expectation in the tested environment—not that the website is legally compliant everywhere. Keep legal conclusions in a separate review owned by qualified counsel or the responsible privacy team.

When a test fails, fix the source rather than hiding the symptom. Hard-coded scripts should be brought under deliberate control; category mappings should be corrected; embeds should follow their intended activation rule; and the banner copy and cookie information should match the live inventory. Review cookie consent best practices for the design and governance layer.

Final cookie banner test checklist

• Define routes, interactions, regions, browsers, and expected categories.
• Start each independent scenario with cookies and all relevant site data cleared.
• Record storage and requests before making a choice.
• Run no-choice, accept, reject, and every granular category state.
• Change and withdraw a saved choice, then reload and revisit.
• Test video, maps, chat, forms, social widgets, and delayed actions.
• Verify Consent Mode defaults, updates, event order, and tag checks if Google tags are used.
• Distinguish basic from advanced Consent Mode when reviewing requests.
• Repeat on mobile, portrait and landscape, keyboard, zoom, and a screen reader.
• Compare automated scan results with manual browser evidence.
• Retest representative pages after relevant releases.
• Keep technical results separate from legal conclusions.

Sources

• EUR-Lex — ePrivacy Directive 2002/58/EC, Article 5(3)
• EUR-Lex — GDPR, Articles 4(11) and 7
• European Data Protection Board — Guidelines 05/2020 on consent
• Court of Justice of the EU — Planet49 judgment, C-673/17
• CNIL — Cookies and other tracking devices: guidelines and recommendation
• Chrome for Developers — View, edit, and delete cookies
• Chrome for Developers — Inspect network activity
• Mozilla Firefox Source Docs — Storage Inspector
• Google for Developers — Set up consent mode on websites
• Google Tag Manager Help — Consent mode and GTM
• W3C — Web Content Accessibility Guidelines 2.2

Ready to compare the matrix with your live site? Run a free cookie scan →