Cookie checker: what a page sets before anyone has clicked
A real Chromium in the EU opens the URL, waits for the banner, records every cookie and third-party request up to that point, then presses Reject all through the CMP's own path and records again. You watch it happen in the live view.
Enter a public page URL. The scan takes fifteen to thirty seconds and shows the browser while it works.
This check opens a real browser on our servers and needs JavaScript in yours.
Observations, not verdicts. What you enter is processed for this result and written to a usage journal described in the privacy policy; nothing else is stored.
How a scan runs
-
The page loads in a fresh browser
No profile, no prior cookies, an EU IP. The scan waits up to five seconds for a consent banner to appear and notes the millisecond it did.
-
The state before any choice is recorded
Every cookie in the jar and every request the page made, grouped by registrable site with a count, is written down as it stands before the banner was answered.
-
Reject all is pressed the way the CMP intends
A recogniser for Usercentrics, Cookiebot, OneTrust, consentmanager and Borlabs finds the deny control or calls the SDK. Where no recogniser matches, a text heuristic looks for a deny button. Nothing is hidden with CSS.
-
The state after the choice is compared
Cookies are listed again. What was there before and is still there, what the CMP itself wrote to remember the decision, and what appeared anyway are shown as three separate lists.
What the report contains
CMP
Which consent tool was recognised, by which signature, or that none was and the heuristic ran.
Banner timing
bannerDetectedAtMs: how long after navigation the dialog was on screen. A banner that arrives after four seconds of scripts is a fact worth knowing.
Cookies before and after
Name, domain, path, expiry and whether it is first- or third-party, once before the choice and once after Reject all.
Third parties before the choice
Every registrable site the page contacted before a decision existed, with the number of requests each received.
Reject path
How the denial happened: which control, on which layer, or that a Reject control was not found and the banner stayed.
What it is not
Observations, not a verdict. The tool does not know what a cookie is for, and it does not read your privacy policy.
How the checker works and where it stops
The scan is an ordinary Browserberg session running the consent report, the same code the consent autopilot uses when an agent opens a page for a customer. There is no model call in it. A container starts, Chromium navigates, and the report is assembled from the browser's cookie jar and its network log. The site's own scans run as metered sessions of a dedicated organisation, capped per visitor and per day, which is why a busy afternoon may ask you to wait.
Why a real browser rather than a fetch
Most cookies that matter are set by JavaScript, often by a tag manager several seconds after the HTML arrived. A server-side fetch of the page sees none of that. The checker waits for the page to settle and for the banner to appear, then reads the jar as Chromium holds it, which includes cookies from third-party frames the page embedded.
The reject path is the interesting part
A consent dialog can be made technically dismissable while still routing a visitor who declines through three screens. The report records how the denial was achieved: through the CMP's deny-all control on the first layer, through its SDK, through a text-matched button, or not at all. The recognisers fail closed. When a CMP has renamed its test ids since the recogniser was written, nothing is pressed, the banner is reported as still open, and the after-choice lists are empty rather than invented.
What the tool deliberately does not decide
A cookie set before the choice is a fact. Whether it needed consent is a question about its purpose, and purpose is not visible from a name and a domain. A session cookie from a load balancer and an advertising identifier look the same to a browser. The report therefore contains no columns called essential, necessary or violation. It also does not read the privacy policy, does not check the cookie list the CMP shows visitors against what was actually set, and cannot see cookies set later on a page you did not scan.
For the same reason the checker states no opinion about § 25 TDDDG or the GDPR. It gives a compliance officer, a developer or a journalist the raw material a discussion needs: the names, the hosts, the timings and the path a refusing visitor is sent down. What that material means for a particular site is a judgement the tool is not qualified to make.
What is kept
The URL you enter is not stored beyond the usage journal that keeps the daily cap honest. The report exists in your browser tab and nowhere else once the session is released.
Questions people ask about cookie scanners
How do I check which cookies a website uses?
Open it in a browser with an empty profile and read the storage panel of the developer tools, or use this checker, which does that in an EU-hosted Chromium and adds the timeline: which cookies existed before the consent banner was answered and which after.
Is this a cookie compliance checker?
No. It reports what happened in a browser. Whether a specific cookie required consent depends on its purpose, which is not observable from the outside, so the tool makes no such call.
Why do cookies still appear after Reject all?
Three reasons show up regularly: the CMP writes a cookie to remember the refusal, first-party cookies such as a session id are set regardless of consent, and some tags fire before the banner and their cookies simply remain. The report separates the three.
Does the scanner accept cookies too?
The public tool presses Reject all. The API behind it takes a policy of reject, accept or detect-only, so a customer's own session can compare all three.
Can I scan a page behind a login?
Not with the public tool, which only takes a URL. In your own Browserberg session the same consent report runs after a credential-vault login on any page the session can reach.
Run the report on every page you automate
Five browser hours, no card. Call the consent report from your own session with reject, accept or detect-only.