Guides

Getting started with Cookie Munch

AdminUpdated Sep 15, 2026

Getting started with Cookie Munch

Cookie Munch is a self-hosted consent management platform (CMP) — a Cookiebot or CookieYes alternative you run yourself. It blocks third-party scripts (analytics, ads, embeds) from firing until a visitor actually consents, writes every decision into a tamper-evident, hash-chained consent log, and gives you a dashboard for managing banners, cookies, and compliance across every domain you own.

This guide walks through the whole path from a fresh account to a live, prior-blocking banner on your site. If you follow it straight through, it takes about five minutes.

The 5-minute path

  1. Create your account and organization — every property, banner, and teammate lives inside an organization.

  2. Add a property — tell Cookie Munch which domain you're protecting.

  3. Install the script — paste one <script> tag into your site's <head>.

  4. See the banner and verify — confirm it renders, test a consent decision, and check the entry land in your consent ledger.

  5. Customize — open Banner Studio to make the banner match your brand, run the cookie scanner, and wire up Google Consent Mode if you use Google Ads/Analytics.

Nothing here requires editing your site's code beyond that one script tag — Cookie Munch's embed does the blocking and the banner rendering for you.

1. Create your account and organization

When you sign in for the first time, Cookie Munch automatically creates a default organization for you. An organization is the container for everything: properties (domains), banner designs, team members, and billing all belong to exactly one organization, and the whole dashboard is scoped to whichever org is currently active.

You can see and switch organizations from the organization switcher at the top of the sidebar. If you need a second organization later (for example, to separate client sites), click the switcher and choose New org. Free-tier accounts are limited to a single organization — see the plans page if you need more.

The first time you land on the dashboard with no live banner yet, an onboarding modal pops up to walk you through the same steps this guide covers. You can dismiss it and come back to it later; it reappears each session until you have at least one property with a verified, live banner.

2. Add your first property

A property is one domain protected by a Cookie Munch banner. Go to Properties in the sidebar (under the "Configure" group) and click Add property:

  1. Domain — enter the bare domain, e.g. acme.com. Cookie Munch normalizes it (strips the https://, lowercases it) for you.

  2. Platform — choose Web, iOS, Android, AMP, or Other. This only changes the install guidance shown to you afterward; it doesn't change the underlying script.

  3. Click Add.

Cookie Munch generates a unique site ID (called a cbid) from the domain plus a random suffix, for example acme-com-9f3k. This ID is how the embed script and the config API identify which banner and settings belong to which site. Your new property shows up as a card with its domain, platform, cbid (click to copy it), and a Pending verification badge.

You don't have to verify ownership before installing — you can paste the script and see the banner immediately — but verification unlocks full dashboard control over the property. When you're ready, click Verify on the property card and pick one of three methods: a DNS TXT record at @ with the value cookiemunch-verify=<token>, a <meta name="cookiemunch-site-verification"> tag in your homepage <head>, or a token file uploaded to a well-known path. Make the change, then click Verify now — checks run on demand, not continuously.

The sidebar also has a property switcher just below the org switcher. It shows which property is currently "active" — the one Banner Studio, Cookies, and other per-site pages operate on. Switching it is instant and remembered on this device.

3. Install the script

Click Install on your property's card to open the snippet dialog, then Copy snippet. The tag is generated specifically for that property's cbid. It looks like this:

<script id="CookieMunch"
  src="https://cdn.cookiemunch.net/consent.js"
  data-api="https://api.cookiemunch.net"
  data-cbid="acme-com-9f3k"
  data-blockingmode="auto"></script>

(data-api only appears when your embed CDN and API run on different origins — which is the normal setup for the hosted CDN. Copy the snippet exactly as generated rather than retyping it, since a mismatched data-cbid is the most common install mistake.)

Where to paste it

Put the tag as high as possible in <head>, before any analytics, ad, or embed scripts — ideally the very first script tag on the page. Placement matters for two reasons:

  • Banner timing. The script needs to run early so the banner appears before visitors can interact with the page.

  • Prior blocking. In auto mode, the embed intercepts script insertions into the DOM from the moment it runs. Anything that loads before the tag is invisible to the blocker and won't be gated.

For a standard site (static HTML, most CMSs and site builders), paste it into your global <head> include. If you manage tags through a tag manager instead, add it as a custom HTML tag that fires on all pages, set to fire as early as possible — ideally outside the tag manager's own async loader, since that defeats the "before every other script" guarantee.

How prior blocking works

data-blockingmode="auto" is the default and the one most sites want: Cookie Munch's blocker rewrites third-party <script> tags it discovers (changing their type so the browser won't execute them) and only "unblocks" — restores and runs — each one once the visitor has granted the matching consent category. Nothing you add to the page after the tag needs any special markup; auto mode discovers and gates scripts on its own. (If you're migrating from Cookiebot, the embed also reads the legacy CookieConsent cookie, so returning visitors aren't re-prompted.)

data-blockingmode="manual" is available for sites that want explicit control over which tags get blocked, using data-cookieconsent markup on individual script/iframe tags — see the developer data-attributes reference if you need that level of control. Most sites should start with auto.

The other attributes you may see:

Attribute

Purpose

id="CookieMunch"

Fixed ID the runtime uses to find its own tag. Keep it as generated.

src

The embed script URL, served from the CDN.

data-cbid

Your property's site ID — tells the embed which config/banner to load.

data-blockingmode

auto (default) or manual.

data-api

The API origin, only present when it differs from the CDN origin.

data-culture

Optional — forces a starting language (e.g. de, fr) instead of auto-detecting from the browser.

The base embed (consent.js) is deliberately small — it contains the banner UI and the blocking engine, and lazily loads a heavier bundle only if you turn on IAB TCF/GPP support, so it stays fast even on the first paint.

4. See the banner and verify

Open your site in an incognito or private window (so you're not carrying over a previous test decision) and reload. You should see the consent banner — by default a bottom bar with Accept all, Reject all, and Customize, plus a preferences modal for granular categories.

To verify blocking and logging actually work end to end:

  1. Reject (or accept) a category, then reload the page. Your choice should be remembered — the banner shouldn't reappear.

  2. Open your browser's dev tools and confirm any third-party scripts you expect to be gated (analytics, ad pixels) don't fire until you've granted that category.

  3. Back in the dashboard, go to Overview (the first sidebar item). The consent ledger panel there lists recent decisions in real time, each with a sha256·<hash> stamp — this is the tamper-evident, hash-chained log: every entry's hash incorporates the previous one, so the chain can be verified and any tampering would break it.

If the banner doesn't appear at all:

  • Open dev tools and confirm the <script> tag is present in the rendered HTML <head> — not injected later by client-side JavaScript, which can run too late for blocking to matter.

  • Check the console for a failed request to consent.js — a stale data-cbid or wrong CDN origin is the most common cause.

  • Double-check the property's verification status; installing works either way, but an unverified property is worth confirming if something looks off.

5. Customize next

Once the banner is live, a few dashboard areas are worth exploring:

  • Banner Studio (sidebar → Banner Studio) — the visual editor for what visitors see. A new organization starts with a polished default banner (bottom bar, granular categories) so you already have something presentable; Studio lets you restyle colors/layout/copy, switch templates, and publish changes, which push live to every property the design is assigned to within seconds — the embed polls its config on load.

  • Cookies (sidebar → Cookies) — the auto-discovered cookie declaration table for your active property, kept current by Cookie Munch's scanner rather than a manual spreadsheet.

  • Privacy Ops (sidebar → Privacy Ops) — DSAR handling, preference-center settings, and governance tooling (RoPA/DPIA) once you need them.

  • Google Consent Mode — if you run Google Analytics or Google Ads, wire up Consent Mode v2 so Google's tags respect the same consent decisions instead of needing their own gating.

Next steps

Was this page helpful?