Free Cookie Scanner: Find Every Tracker on Your Site

You cannot honestly ask visitors to consent to cookies you do not know exist. Yet most sites are running trackers nobody on the team can name: things injected by a tag manager, an embedded video, a chat widget, or a marketing pixel a contractor added two years ago. Before you place a single consent banner, you need a complete inventory. That is what a cookie scanner is for.

This guide explains what a cookie scanner actually does, why scanning has to come before consent, and how to run a free cookie scan on your own site in a couple of minutes, no account required.

What a cookie scanner does and why it matters for compliance

A cookie scanner loads your website the way a real visitor would, then records everything that gets stored on the device: HTTP cookies, but also localStorage, sessionStorage, and the third-party scripts that set them. A good website cookie scanner gives you a categorized list of every cookie, who set it, what it is for, and how long it persists.

That inventory is the foundation of every compliance task that follows. You cannot write an accurate cookie policy without it. You cannot configure a consent banner that actually blocks the right scripts without it. And you cannot answer a regulator or a customer asking "what do you collect?" without it.

The catch is that scanners are not all equal. Many free tools simply read your page's HTML source and report the cookies declared there. The problem is that the most invasive trackers are rarely in the source. They are loaded dynamically, by JavaScript, after the page renders, often by other scripts that were themselves loaded by a tag manager. A source-only scanner is blind to all of that.

The trackers that create the most legal exposure are usually the ones a source-only scanner cannot see, because they are injected at runtime, not written into your HTML.

This is why CookieBrain runs every scan in a real headless browser. It actually executes your page, fires the tag manager, lets the embeds and pixels load, and captures the cookies they set in practice rather than in theory. That is the difference between a list that looks complete and one that is.

GDPR, CCPA and ePrivacy: why you must scan before you set a banner

The major privacy regimes do not just ask you to show a banner. They ask you to be accurate, and accuracy starts with knowing your own trackers. (This is general information, not legal advice; check your specific obligations with a qualified advisor.)

• The EU ePrivacy Directive (the actual source of the "cookie law") requires consent before storing or accessing non-essential cookies on a user's device. You cannot get valid prior consent for trackers you have not catalogued.
• The GDPR sets the standard for what consent must look like: freely given, specific, informed, and unambiguous. "Informed" means your banner and policy have to describe what is actually running.
• The CCPA/CPRA in California focuses on the sale and sharing of personal information and the right to opt out. To honor those rights, you first have to know which third parties your site is feeding data to.

In every case, the consent banner is the visible output. The cookie scan is the invisible input that makes it truthful. Set the banner first and you are essentially guessing, and a banner that blocks the wrong scripts (or none of them) can be worse than no banner at all, because it documents an intention you are not actually meeting.

First-party vs third-party cookies and hidden trackers

To read a scan you need two distinctions.

First-party cookies are set by your own domain. These are often the benign, functional ones: keeping a user logged in, remembering items in a cart, storing a language preference. Many are strictly necessary and do not require consent. But "first-party" does not automatically mean "essential", some first-party cookies feed analytics or personalization and still need consent.

Third-party cookies are set by other domains loaded into your page: ad networks, social widgets, analytics providers, A/B testing tools. These are the ones regulators care most about, and the ones a banner must gate behind consent.

The trouble is the hidden layer. Consider a few common cases:

• You install Google Tag Manager once. Marketing then adds tags through it without touching your codebase, so new trackers appear that engineering never sees.
• You embed a YouTube video. The default embed loads cookies the moment the page renders, before anyone clicks play.
• A live-chat or support widget loads its own analytics and session tools as a dependency.
• A pixel set by one ad platform daisy-chains and loads another.

None of these show up reliably in your HTML source. A real-browser cookie scanner tool catches them because it watches what the live page does, not what the markup claims.

How to scan your website for cookies (free, in your browser)

You do not need to install anything or create an account to get a complete picture. Here is the fastest path with a free cookie scanner:

1. Go to the scan page and enter your full URL, including https. Use your real production homepage, not a staging copy, because staging often omits the marketing tags that matter.
2. Start the scan. CookieBrain opens your site in a real headless browser, lets scripts execute, and records every cookie and storage entry that gets set.
3. Wait a few seconds. The scan needs to let dynamic scripts and embeds finish loading, which is exactly the step source-only tools skip.
4. Read the categorized results: necessary, analytics, marketing, and anything it could not confidently classify.

One practical tip: scan more than your homepage. Different pages load different trackers. A blog post may carry social embeds your homepage does not; a checkout page may load payment and fraud tools; a landing page may fire campaign pixels. If a tracker only appears on one template, a homepage-only scan will miss it.

Reading your scan results: necessary, analytics, marketing, unclassified

A raw list of cookie names is not useful on its own, the value is in the categorization. CookieBrain uses AI to classify each cookie so you can act on it:

• Necessary / strictly essential. Cookies required for the site to function: session management, security tokens, load balancing, basic cart state. Under most frameworks these do not require consent, but the bar for "necessary" is narrow. A cookie that improves the experience is not the same as one the site cannot run without.
• Analytics / statistics. Tools that measure traffic and behavior, like web analytics platforms. In the EU these generally require consent before they run. This is the category where a lot of sites quietly fall out of compliance.
• Marketing / advertising. Ad pixels, retargeting tags, and conversion trackers. Almost always consent-gated, and the most sensitive from a CCPA "sharing" standpoint.
• Unclassified. Cookies the scanner cannot confidently place. Treat these as the start of an investigation, not noise. An unclassified cookie often turns out to be a third-party tracker nobody documented, exactly the kind of thing that creates risk.

Work the unclassified bucket first. Each entry there is a question you currently cannot answer about your own site, and "we did not know it was running" is not a defense anyone wants to test.

How often you should re-scan

A cookie scan is a snapshot, not a permanent certificate. Your tracker footprint drifts constantly, often without a code change, because tag managers, third-party scripts, and embedded services update themselves.

A sensible cadence:

• Re-scan whenever you add a tool, a new analytics platform, ad pixel, chat widget, video embed, or A/B testing script.
• Re-scan after any tag manager change, since that is precisely where new trackers slip in without touching your repo.
• Run a periodic scan (monthly is reasonable for active sites) to catch third-party scripts that changed what they load on their end.

Manual periodic scanning is fine for a single small site. If you manage many sites, or your stack changes often, continuous monitoring is the safer model, which is one reason CookieBrain re-scans connected sites on an ongoing basis rather than once at setup.

From scan to compliant banner

The scan tells you what is on your site. The banner does something about it. The link between the two is what separates a real consent setup from a cosmetic one.

Here is the workflow CookieBrain is built around:

1. Scan your site in a real browser to get the complete, categorized cookie inventory described above.
2. Review and confirm the categories, especially anything that landed in unclassified, so the banner reflects reality.
3. Generate a banner that maps to those categories and actually blocks non-essential scripts until the visitor consents, rather than just displaying a notice while everything fires anyway.
4. Install one line. A single script tag serves the banner from Cloudflare's edge in under 50ms, on any stack, WordPress, Shopify, Webflow, or custom code, with support for Google Consent Mode v2, IAB TCF v2.2, and geo-targeting so visitors see the right rules for their region.

That last step matters more than it sounds. A banner that loads slowly hurts your Core Web Vitals and your conversion rate; a banner that does not genuinely gate scripts hurts your compliance posture. Doing both well is the point.

Start with the free scan, it costs nothing and tells you exactly where you stand. Run a free cookie scan on your site right now and see every tracker, classified, in under a minute. When you are ready to turn that inventory into a working, edge-served consent banner, you can start a 14-day CookieBrain trial with no card required and no free-plan strings attached. Knowing what is on your site is step one, and it is free.