b2KIT

Cookie Consent Compliance Scanner

Scan a site for cookie consent compliance. Check if cookies are set before consent and categorize by purpose.

Tested tool guide Tested browser tools Checked August 16, 2026

What Cookie Consent Compliance Scanner does, with a checked example

A site's homepage loads, its scripts fire, and cookies land in the visitor's browser before anyone has clicked a thing. This scanner automates that first visit: give it a URL and it loads the page without touching the consent banner, records every cookie that appears, and categorizes each one by purpose - strictly necessary, preferences, analytics, or advertising - flagging any that legally needed consent first. The surprise most people hit: a clean report is not proof of compliance. The scanner cannot click through a banner or replay a full human session, so consent-gated cookies can go unseen.

Worked example

A concrete input and expected output from the current implementation.

Input

https://shop.example.com

Expected output

Report for https://shop.example.com - no consent given, page idle for 10 seconds after load

7 cookies observed:
PHPSESSID (session) - strictly necessary - pre-consent: OK
cookie_consent (persistent) - strictly necessary - pre-consent: OK
_ga (2 years) - analytics - pre-consent: violation
_gid (24 hours) - analytics - pre-consent: violation
_gat (1 minute) - analytics - pre-consent: violation
_fbp (3 months) - advertising - pre-consent: violation
_uetsid (30 minutes) - advertising - pre-consent: violation

By purpose: 2 strictly necessary, 3 analytics, 2 advertising
Set before consent: 5 of 7 (71%); consent required for 5
Verdict: non-compliant - analytics and advertising cookies set before consent

The five cookies whose purpose is not strictly necessary appeared before any consent was given, which Article 5(3) of the ePrivacy Directive permits only for the two exempt cookies: the session identifier and the cookie that records the consent choice itself. The verdict follows directly from the five-to-two split.

How the result is produced

1

What the scan captures

The scan loads the target URL in a clean context with no stored cookies for that domain, lets the page and its scripts settle for several seconds, then snapshots every cookie the context can see. Nothing is clicked, so the report reflects the pre-consent state only. A second snapshot catches scripts that write cookies late in page load, so deferred trackers still surface.

2

How cookies are categorized

Each cookie name is matched against a library of known tracking families - _ga, _gid, and _gat resolve to Google Analytics, _fbp to Meta's pixel, _uetsid to Microsoft's ad tracking - and assigned a purpose category. Names that match nothing are reported as unclassified rather than silently guessed. Only strictly necessary cookies (session handling, security, recording the consent choice) are treated as consent-exempt.

Good uses

  • Pre-launch check: after wiring up a consent manager on your own site, scan it to catch tracking cookies that still fire before the banner is answered.
  • Vendor review: scan a third-party site before embedding its scripts, to see whether you would inherit pre-consent tracking by default.
  • Audit documentation: capture a first-visit cookie inventory and purpose breakdown for a privacy review, an outside consultant, or a renewal decision.

Limits and checks

  • Absence is not compliance: cookies that appear only after interaction, or that the scan context cannot execute, never reach the report. A clean run can mean a careful site, or simply a scan that could not see the tracking.
  • Categories are heuristics: a cookie named _ga is assumed to be Google Analytics, and a tracker with a custom name lands in unclassified. Read the purpose column as a strong hint, not a guarantee.
  • One run is one moment in time: results shift with geo-targeting, A/B tests, and rotating banners, and the scan context must start with no prior consent state or a returning-visitor response can mask first-visit cookies.

Common questions

The report says nothing was set before consent. Is the site compliant?

Not necessarily. The scan proves only that no observable cookie appeared during a scripted first visit. Interaction-dependent cookies, cookie writes the scan context cannot execute, and a dirty starting state can all slip through. A clean result is a good sign to investigate further, not a legal clearance.

If my site passes the scan, am I safe from regulators?

No. Pre-consent cookie behavior is one technical slice of a bigger picture: the banner itself must obtain valid consent - freely given, specific, informed, unambiguous - and you still need records of consent, a truthful privacy notice, and compliance with national rules implementing the ePrivacy Directive. The scanner checks the pattern, not the paperwork, and it is not legal advice.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools