Technical breakdown:

TLDR We run your site in a real browser (Playwright), intercept network traffic and cookies, and run 90+ checks on actual runtime behaviour. Static tools that only read HTML or cookie lists miss the violations that matter: trackers firing before consent, dynamic script injection, and fourth-party chains.

The gap

Most "cookie scanners" do static analysis: they fetch the page, parse HTML, and list cookies. They don't see what happens after load. In practice, a lot of tracking is injected later — via GTM, consent-dependent scripts, lazy-loaded widgets. So you can get a "compliant" report while Google Analytics, Meta Pixel, or Criteo still fire before the user clicks Accept.

GDPR and the ePrivacy rules care about behaviour: consent before non-essential processing. Regulators and technical audits increasingly look at what actually ran, not what your policy says. A static snapshot can't answer "Did tracking start before consent?" — only runtime observation can.

What we do instead

We don't guess from source code. We run the site in a real browser and observe execution order.

Real browser: Playwright driving Chromium, with desktop and mobile viewports (e.g. 1920×1080 and 390×844). Same engine as a real user; same script execution, same third-party loading.

Full network interception: Every HTTP/HTTPS request — URL, headers, timing, POST body when relevant. So we see when each tracker fires relative to page load and to any consent interaction.

Cookie monitoring: Set-Cookie from responses (main frame and third-party), plus what ends up in browser storage and document.cookie, with timing. That lets us classify cookies (tracking vs essential vs consent-dependent) and flag ones set before consent.

100+ checks: Pre-consent data leaks, banner behaviour (does Accept actually remove the banner and block further tracking?), known tracker domains (hundreds of ad-tech, analytics, social, video vendors), and high-risk patterns — fingerprinting, AI/ML scripts, cross-border flows. Each finding is tied to evidence: request URL, domain, and whether it ran before or after consent.

So when we say "8 tracking cookies set before consent," we're not inferring from a cookie list — we're reporting what we saw in the browser trace with full list of all the data.

Sample data:

{
 "status": "FAIL",
 "cookies": {
 "tracking": [
 "datr",
 "_fbc",
 "_fbp"
 ],
 "essential": [],
 "consent": [],
 "unknown": [],
 "classificationReasons": {
 "datr": "First-party tracking cookie (requires consent)",
 "Fbc": "First-party tracking cookie (requires consent)",
 "Fbp": "First-party tracking cookie (requires consent)"
 },
 "counts": {
 "tracking": 3,
 "essential": 0,
 "consent": 0,
 "unknown": 0,
 "total": 3
 }
 },
 "thirdPartyTrackingCount": 0
}

Why it matters for builders and auditors

If you're responsible for an EU-facing site — as a founder, CTO, or DPO — you need evidence. "These N trackers fired before consent" is the kind of statement that holds up in a technical audit. Static tools can support an inventory; they can't prove or disprove consent bypass. The bar we built for is: run the site in a browser and check when each tracker fired.

We don't implement consent or block trackers.
We audit whether your setup blocks correctly and give you remediation guidance. Consent tools help you collect consent; we tell you if you're breaking GDPR.

Try it yourself

Free runtime scan at https://securespells.com — no signup, no email gate.

You get the same pipeline:
Playwright, network interception, checks, evidence-based risk score.
I'm happy to go deeper on the audit pipeline or check design in the comments.