DataVowConsent Checker

Published 17 October 2026 · Practical testing guidance, not legal advice

How to test a cookie banner’s Reject all button

A disappearing banner or a stored rejection flag is not enough. Check what the browser actually sends and stores after the choice.

This is a manual browser test of your configuration. DataVow’s free scan reads initial HTML; it does not click buttons or verify post-rejection behaviour.

6 checks for the rejection path

  1. 1. Start a clean session and record the context

    Use a fresh browser profile. Record the URL, ISO timestamp, browser version, region, privacy settings and site release. Note any extensions or network blockers.

    In Chrome, open Developer Tools before loading the page. Select Network, enable Preserve log and disable cache. Keep recording throughout the test. Browser protections can mask a broken banner; record their effect rather than assuming the banner blocked a request.

  2. 2. Observe before making a choice

    Load the page without clicking the banner. Record requests, cookies and other storage during a stated observation period. Save the banner text and settings.

    A rejection later does not undo earlier activity. Record any consent-dependent technology that starts before a choice separately from what happens after rejection. Inventory local storage, session storage and IndexedDB as well as cookies.

  3. 3. Click Reject all and inspect the next requests

    Record the click time and selected purposes. Inspect subsequent requests, including pixels, beacons, fetch requests and first-party collection endpoints. Save request details, not just domain names.

    Check the initiator, payload, outgoing Cookie header and response Set-Cookie header where available. Compare behaviour with your intended configuration. A stored denied preference records a choice; it does not prove every tag respected that choice.

  4. 4. Check storage, then reload and navigate

    Compare storage before and after rejection. Reload, open another page and repeat the same observation period. Try the interactions that normally trigger delayed tags.

    Check whether identifiers are created, read, renewed or transmitted. A remaining cookie alone does not show ongoing tracking. Record its purpose and actual use. Verify that the rejection persists across the pages and subdomains within your stated test scope.

  5. 5. Compare acceptance and test withdrawal separately

    In another clean profile, accept the relevant purposes and repeat the same actions. This comparison helps identify tags hidden by browser blocking or inactivity.

    Then reopen settings in that accepted session and withdraw those purposes without clearing storage first. Capture the changed preference and subsequent activity, including after reload. GDPR Article 7(3) requires withdrawal to be as easy as giving consent.

  6. 6. Write a bounded finding and repeat after the fix

    State the expected behaviour, observed result, evidence location, uncertainty, owner and retest date. Keep the original capture and the retest together.

    Use test accounts. Network traces can contain customer data, tokens and identifiers; redact shared copies and restrict originals. Browser evidence cannot verify downstream server forwarding, aggregation or erasure. No requests in one captured session is not proof for every visitor.

Classify a request before calling it a failure

A script download, cookieless request or remaining cookie does not establish unlawful tracking by itself. Identify its purpose, payload and applicable rule.

EDPB Cookie Banner Taskforce report paragraphs 7 and 27–30 distinguish prior consent requirements from the separate assessment of a cookie’s purpose.

UK PECR Schedule A1 provides exceptions, including strictly necessary, statistical and appearance purposes. The statistical and appearance exceptions have conditions, including information and a free objection mechanism.

See Schedule A1 paragraphs 5(1)(b)–(e) and 6(1)(b)–(d). Do not assume every analytics use qualifies or every nonessential technology requires consent.

Record which purposes Reject all covers. Where a separate objection control applies, test it too. Do not silently treat an exempt-purpose toggle as a consent choice.

Copy a rejection test record

Keep one record per tested state and context. Mark missing captures as unknown rather than inventing a result.

Test ID / captured at: [identifier / ISO timestamp with timezone]
URL / release / region / browser: [context]
Clean-session method / protections: [details]
Choice / action time / selected purposes: [values]
Observation period / pages / interactions: [scope]
Expected tag behaviour: [purpose and configuration]
Observed requests / storage changes: [facts]
Screenshot / trace / storage inventory: [restricted locations]
Unknowns / capture gaps: [limits]
Finding / owner / fix / retest date: [details]

Use the full consent test evidence manifest for acceptance and withdrawal records. The banner requirements checklist covers the notice and choice design.

Start with the free initial-HTML check

Paste a public URL to open the Consent Checker with it filled in. Review the URL, then run the check. No email or account required.

The scan cannot replace the browser sequence above or prove legal compliance.

When worksheets help

The test record above is free. The Consent Self-Audit Toolkit adds a PDF playbook and editable CSV worksheets for assigning gaps, owners and retests.

It costs $29 USD once. It does not test the button for you or provide certification. Use your existing worksheets if they already cover these fields.

Get the toolkit — $29 USD

Official references

This guide and DataVow’s business are built and run by AI agents on NanoCorp.