Docs
Product
Developer

Embed scripts (consent.js)

AdminUpdated Sep 15, 2026

Embed scripts (consent.js)

Every site is protected by a single <script> tag. It loads consent.js — a small, dependency-free IIFE — which installs prior-blocking, fetches your site's config, and renders the banner.

The install tag

<script id="CookieMunch"
  src="https://cdn.cookiemunch.net/consent.js"
  data-api="https://api.cookiemunch.net"
  data-cbid="your-site-id"
  data-blockingmode="auto"></script>

Place it as early as possible in <head> — before any analytics/marketing tags — so prior-blocking can intercept them. The generated snippet for a given site is also available programmatically:

curl https://api.cookiemunch.net/v1/sites/YOUR_CBID/snippet \
  -H "Authorization: Bearer fck_…"
{
  "snippet": "<script id=\"CookieMunch\"\n  src=\"https://cdn.cookiemunch.net/consent.js\"\n  data-cbid=\"your-site-id\"\n  data-blockingmode=\"auto\"></script>",
  "src": "https://cdn.cookiemunch.net/consent.js",
  "api": "https://api.cookiemunch.net",
  "cbid": "your-site-id",
  "blockingMode": "auto"
}

Note: The element id may be CookieMunch or Cookiebot — the embed looks for either (in that order), then falls back to document.currentScript. This is what makes drop-in migration from Cookiebot possible: existing id="Cookiebot" tags keep working unmodified.

Attributes

Attribute

Required

Values

Description

src

yes

URL

The consent.js embed origin. https://cdn.cookiemunch.net/consent.js by default; your own domain if self-hosting the static asset.

data-cbid

yes

string

The site identifier issued when you create the site. Without it the embed refuses to start.

data-blockingmode

no

auto | manual

Auto-blocking strategy. auto (default) installs the DOM-interception blocker; any other value (including checklist, accepted by the snippet builder for forward-compat) is treated as manual — you mark tags inert yourself.

data-api

no

URL

Overrides the API origin used for config fetch + beacons + the lazy consent-tcf.js bundle. Only needed when consent.js is served from a separate static CDN than the API — otherwise the embed derives the API origin from its own src.

data-culture

no

BCP-47 tag, e.g. en, fr

Force the initial banner language, overriding auto-detection from navigator.language.

All three functional settings (cbid, blockingmode, culture) can also be supplied via window.CookieMunchConfig = { cbid, blockingmode, culture } (useful when a tag manager can't set data-* attributes) or as query parameters on the script src (?cbid=…&blockingmode=…). Precedence is data-* attribute > window.CookieMunchConfig

src query string.

What consent.js does on load

  1. Installs prior-blocking synchronously, before fetching anything — so no tracker script that loads later in the page can slip through the window between page-load and config-fetch. See script blocking & data-attributes.

  2. Fetches the live config from GET <api-origin>/config/:cbid and re-normalizes the blocker/banner/framework settings against it. If the fetch fails (offline, CORS, outage), it falls back to the attribute-only base config rather than leaving the page unprotected.

  3. Detects the visitor's region (server-provided) and resolves the banner mode (opt-in / opt-out / off) per your geo rules, honoring Global Privacy Control (GPC) as a forced decline where applicable.

  4. Renders the banner (or applies implied consent silently, depending on mode) and exposes window.CookieMunch — see the JavaScript API.

  5. Beacons anonymous impression + consent-decision events back to the API origin. These calls are unauthenticated by design (the embed runs in an untrusted browser); authenticated read access to the resulting data goes through consent log, stats & export.

consent-tcf.js (lazy IAB bundle)

When a site has framework: "iab" (TCF), GPP, or US-Privacy enabled, consent.js installs synchronous __tcfapi / __gpp / __uspapi stubs immediately (so any ad tech checking for them on page-load sees a valid, if pending, API), then lazily loads consent-tcf.js in the background. That bundle carries the IAB TC-string encoder/GVL lookup logic (@iabtcf/*-derived), which would otherwise bloat the base embed for the majority of sites that don't need IAB compliance. Once loaded, it re-encodes the TC string on every explicit accept/decline and dispatches it through the stub to any listener (addEventListener('addEventListener', …)) already registered by ad tags.

You never load consent-tcf.js yourself — it is fetched automatically, from the same API origin as the beacons, only when needed.

Cookiebot compatibility

Cookie Munch's embed is designed as a drop-in replacement for Cookiebot's script:

  • The install tag accepts id="Cookiebot" in addition to id="CookieMunch".

  • window.Cookiebot is exposed as an alias of window.CookieMunch (same object).

  • Lifecycle events are dispatched under both CookieMunch<Event> and Cookiebot<Event> names, and both CookieMunchCallback_<Event> and CookiebotCallback_<Event> globals are invoked if defined.

  • The legacy data-cookieconsent script-blocking attribute is recognized (see script blocking & data-attributes).

This means most Cookiebot integrations (ad-network wiring, custom onConsentReady handlers) work by swapping the <script> tag with no other code changes.

Next: JavaScript API for window.CookieMunch, or script blocking & data-attributes for prior-blocking markup.

Was this page helpful?
Embed scripts (consent.js)