Guides
Getting started
Banner & appearance
Scanning & cookies
Consent & compliance
Records & privacy

Installing the script

AdminUpdated Sep 15, 2026

Installing the script

Every property is protected by exactly one <script> tag. This guide covers the exact snippet Cookie Munch generates for you, what each attribute does, where to paste it for common setups, and how to confirm it's actually working.

Get your snippet

From Properties, find your site's card and click Install. The dialog shows a tag built specifically for that property — it's not a generic copy-paste block, it's generated with your site's real cbid baked in. Click Copy snippet to grab it.

A generated tag looks like this:

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

If your embed origin (where consent.js is served from — typically a CDN) is different from your API origin, the tag also carries a data-api attribute:

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

Always copy the snippet as generated rather than retyping it — whether data-api appears at all depends on how your instance is deployed, and it's easy to drop by accident if you're typing from memory.

Every attribute, explained

Attribute

Required

Purpose

id="CookieMunch"

Yes

Fixed ID the runtime (and the legacy Cookiebot id, for migrations) uses to find its own tag on the page. Leave it as generated.

src

Yes

The URL of the embed script itself, served from your CDN/embed origin.

data-cbid

Yes

Your property's unique site ID. This is what ties the embed to the right banner design and config in your dashboard — get this wrong and the banner simply won't find its config.

data-blockingmode

No (defaults to auto)

auto rewrites third-party <script> tags so the browser can't execute them until consent is granted for their category. manual instead only unblocks scripts you've explicitly marked with data-cookieconsent attributes, giving you fine-grained control. Anything other than auto is treated as manual.

data-api

Only when embed and API origins differ

The origin the embed beacons consent events to and fetches remote config/consent-tcf.js from. Present automatically when needed; don't add or remove it by hand.

data-culture

No

Forces a starting language (e.g. de, fr) instead of letting the embed auto-detect from the visitor's browser.

Configuration can also be supplied via a window.CookieMunchConfig object or as query parameters on the script's own src URL, in case your setup can't add data-* attributes to an injected tag (Google Tag Manager's sandboxed script injection is the common case). Precedence when more than one source is present is: data-* attributes win, then window.CookieMunchConfig, then the query string.

Where to put it

Paste the tag as high as possible in <head> — before any analytics, ads, or embed scripts. Placement matters for two distinct reasons:

  • Banner timing. The script has to run early enough to show the banner before a visitor can interact with anything the banner is meant to gate.

  • Prior-blocking coverage. In auto mode, the embed only intercepts scripts from the moment it runs onward. A tracking tag that's already inserted into the page before your Cookie Munch tag executes is invisible to the blocker — it will fire unblocked regardless of consent state.

Raw HTML

Paste the tag directly into the site's shared <head> include (a layout template, header partial, or master page) so it appears on every page, not just one.

Google Tag Manager

Add it as a Custom HTML tag, triggered on All Pages, and set its priority so it fires as early as possible — ideally outside of GTM's own async container loader, since GTM's default load timing is already later than you want for prior-blocking. Because GTM injects the tag into the DOM programmatically, it may not preserve your data-* attributes reliably in every configuration — if the banner behaves unexpectedly, fall back to window.CookieMunchConfig or the src query-string form described above.

WordPress

Add the snippet via your theme's header template (header.php, before </head>) if you have theme access, or through a header/footer injection plugin pointed at "before </head>" / "site-wide head." Avoid plugins that defer or async-load injected scripts — that undermines prior-blocking the same way GTM's default timing does.

Common site builders (Webflow, Squarespace, Shopify, etc.)

Most builders expose a Custom code / head code setting in site-wide settings (not a per-page embed) — use that rather than a page-level embed block, so the tag lands on every page including ones you add later. Paste the tag exactly as copied.

Confirming it loaded

Reload your site in an incognito/private window (a fresh session avoids being misled by a stale local consent decision) and check:

  1. The banner renders. If it doesn't, open dev tools → Elements/Inspector and confirm the <script id="CookieMunch"> tag is actually present in the rendered HTML — some builders or a strict Content-Security-Policy can silently strip or block it.

  2. The Network tab shows the request for consent.js succeeding (200, not a CORS or 404 failure) from the origin in src.

  3. A choice sticks. Accept or reject, then reload — the banner shouldn't reappear with the same choice.

  4. Verification flips from Pending. Back on the Properties page, once the embed has beaconed from your live domain the property's verification status may already move to verified on its own; otherwise run one of the manual verification methods described in Properties.

If the banner still doesn't show, double-check the data-cbid matches the property you copied it from — a stale snippet from a different property (or a typo) will load successfully as a script but never find a matching config to render.

Was this page helpful?