A consent platform built to enforce, not decorate.

The problem with most cookie banners

Cookie compliance under the GDPR and the ePrivacy rules has one hard technical requirement: non-essential cookies and trackers may only run after the visitor agrees. Yet the default way analytics and marketing tags are installed — a script tag that executes on page load — violates that by design. A banner bolted on top changes nothing: by the time it renders, Google Analytics has set its cookies and the Meta Pixel has fired. Regulators have repeatedly fined exactly this pattern. A consent tool that does not block is a liability with a UI.

How CookieCrumb works, end to end

1. A ~18 KB loader that fails closed

You install one script tag. The loader it delivers is roughly 18 KB of dependency-free JavaScript — several times smaller than typical consent bundles — and it is generated per site, with your banner configuration baked in, so there is no extra round-trip to fetch settings. It renders the banner inside Shadow DOM, which means your site's CSS and the banner cannot break each other.

Crucially, the loader fails closed. Scripts you tag with a category are held before they execute: a held script has type="text/plain", which browsers refuse to run. Only when the visitor accepts a category are the scripts in that category released. No consent, no execution — not the other way around. Tagging is explicit — the loader does not guess which untagged scripts are trackers — and the WordPress and Drupal plugins do it for you by script handle or library. Google tags are additionally covered by Consent Mode v2, set to denied by default.

2. A scanner that browses like a person

You cannot get consent for cookies you don't know about. CookieCrumb ships two scan engines. The default crawler fetches your pages and inspects responses and headers — good for quick inventories. The optional deep engine, enabled per deployment, loads each page in headless Chromium, executes its JavaScript, and records the cookies that actually get set — which is how it catches the client-side and third-party cookies that header-only scanners structurally miss. If it detects an existing consent platform on the site, it also reads that platform's declared cookies and vendors, so migrations start from your current declaration instead of a blank page.

Detected cookies are matched against a built-in list of well-known services and sorted into the banner's categories — Necessary, Preferences, Analytics, Marketing. Cookies that match nothing are listed as Uncategorized so you can see what still needs a decision.

3. Proof of ownership before deep access

Before a site can be deep-scanned in production, its owner proves control of the domain — via a DNS TXT record, a .well-known file, or a homepage meta tag. This is a deliberate friction: it prevents anyone from pointing our infrastructure at a site they don't own, and it means the scans your compliance depends on were authorized by you.

4. A consent record that stands up to an audit

Every visitor decision is beaconed back and stored as an immutable event: a pseudonymous consent ID, timestamp, banner version, and the exact categories accepted or rejected. IP addresses are masked by default, so the log is valid legal proof without becoming a privacy problem itself. You can filter and export it from the dashboard as CSV, or pull it over the API — this is the artifact you hand a regulator when they ask you to demonstrate consent under GDPR Article 7(1).

5. Signals and languages handled for you

Translations are editable per site, and with auto-detection on the banner follows the visitor's browser language. Turn on Respect Global Privacy Control and browsers that send the GPC signal are opted out of optional tracking automatically, without a banner — a legal requirement in California and good manners everywhere else.

6. An API surface equal to the dashboard

Everything the dashboard does — creating sites, reading the install snippet, verifying ownership, scanning, updating banner config, reading stats and the consent log — is available over a documented REST API with standard OAuth 2.0 tokens. The API is described by an OpenAPI 3.1 document and discoverable through /.well-known metadata, which makes CookieCrumb operable by CI pipelines and AI agents, not only by humans in a browser.

Why teams pick CookieCrumb

• Compliance that is real. Tagged scripts stay blocked until consent, Reject is as prominent as Accept, and the consent log exists from day one — the three things regulators actually check.
• Performance you don't pay for. ~18 KB versus the 48–120 KB of typical consent scripts. The one tag that loads on every page should be the smallest one.
• Honest pricing. Free for one domain, flat paid tiers, no per-consent metering. Your traffic growing is not a billing event.
• No lock-in theater. Your cookie inventory, banner config, and consent log are all exportable over the API at any time.
• Built for automation. From scan scheduling to agent self-service, the platform assumes machines will operate it — because increasingly, they do.

Where the limits are

We would rather tell you this than have you discover it. CookieCrumb is focused on cookie and tracker consent: it is not a full enterprise privacy suite — no DSAR workflows, no vendor risk management, no data mapping. If you need those, a platform like OneTrust is the right tool and we say so in our comparison pages. And no consent platform can make an unlawful data practice lawful: we enforce the choices your visitors make; what you do server-side with data remains your responsibility.