A Cookie Checker That Reads the Headers, Not the Marketing

What the Report Grades

• Cookies Every Set-Cookie along the redirect chain: flags, path, lifetime and what the cookie is for, from a list of a few hundred known names.
• Trackers Third-party hosts in the HTML, sorted into advertising, analytics, social, session replay, tag managers and plain asset hosts.
• Consent A consent platform (Cookiebot, OneTrust, iubenda, CookieYes and about twenty more), Google Consent Mode and a policy link.
• Storage Inline document.cookie writes and localStorage or sessionStorage use.
• Reachability Status, redirects and whether the page is on HTTPS at all.

Each check is marked pass, warning or fail and rolled into one score out of 100.

How One Fetch Turns Into a Report

Enter a URL and cookiecheck.tools fetches that page once, from this site's server, following redirects and keeping the headers of every hop. Each Set-Cookie header is parsed attribute by attribute: name, value length, Domain, Path, Expires or Max-Age, Secure, HttpOnly, SameSite, Partitioned and the __Host- and __Secure- prefixes. The name is matched against a list of a few hundred known cookies so _ga reads as "Google Analytics client id, analytics, typically 2 years" instead of a bare string.

Then the HTML is read, not executed. Every script, iframe, image, link and inline-script URL that points off-site is collected, its host reduced to a registrable domain and looked up in a table of roughly 200 tracker, ad, social, session-replay, tag-manager, consent-platform and asset hosts. Consent platforms are detected by host and by the JavaScript signatures they leave in the page (OneTrust's OptanonWrapper, Cookiebot's CybotCookiebot, and so on), along with Google Consent Mode and a link to a cookie or privacy policy.

What it cannot see, and why there is a second tab

The page is fetched, not rendered. No JavaScript runs on this server, so a cookie that Google Analytics or the Meta Pixel writes from a script never appears in the URL report, and neither does anything a tag manager injects after load. That is a deliberate limit: rendering strangers' pages in a headless browser costs a lot of memory on a small shared server and would still miss cookies set after a click or a scroll.

The browser tab covers that gap honestly. You paste a short snippet into your own browser's console on the page you care about, it reads document.cookie, localStorage and sessionStorage and prints them as JSON, and you paste the JSON back here. The classification runs in your tab and nothing is sent to this server. HttpOnly cookies do not show up there, by design, which is why the two views complement each other rather than compete.

What it will never do

No accounts, no stored history, no PDF quotes, no "compliance certified" badge. The page is fetched, parsed in memory and forgotten. Requests are rate limited per visitor so the fetcher cannot be turned into someone else's scanner, and it refuses to fetch private or internal addresses. Whether a given setup is lawful in a given country is a legal question; the report shows what is set and what gates it, which is the factual part of that question.

Who it's for

Developers checking that a session cookie really carries HttpOnly and SameSite after a deploy. Site owners who installed a consent banner and want to know whether trackers still fire before the visitor clicks. Privacy-minded people who want to know what a site put in their browser. If a verdict looks wrong, the contact page explains what to send. For the security headers on the same response, our sister tool securityheaders.tools reads the rest.