Debug Cookiebot in Chrome DevTools

What Cookiebot traffic looks like

A Cookiebot deployment loads in stages (stub, per-domain config, banner assets) while the consent decision lives in a cookie and on window.

Endpoint pattern

consent.cookiebot.com/uc.js carrying the site's cbid GUID as a query parameter or data-cbid attribute; per-domain declaration config cd.js under a consent.cookiebot.com/<cbid>/ path; banner assets from consentcdn.cookiebot.com or the EU variant consentcdn.cookiebot.eu

Transport

Script loads plus consent-state syncs back to the consent CDN, so the signed state survives across subdomains

Cookies

CookieConsent: URL-encoded object with boolean category flags necessary, preferences, statistics, marketing plus a stamp identifier; appears in two wild formats (proper JSON or a JavaScript object literal with unquoted keys), which matters if you parse it by hand

Data layer objects

window.Cookiebot.consent exposes the live state; lifecycle pushes CookiebotOnLoad, CookiebotOnDialogDisplay, CookiebotOnAccept, CookiebotOnDecline, CookiebotOnTagsExecuted

Debugging Cookiebot with Event Watcher

• Detected from its network requests (uc.js, the cd.js config, and consentcdn calls), each shown in the live stream with the platform name, icon, and Consent Management badge.
• No dedicated payload parser: you get the raw request with parsed query parameters plus cookies sent and set per event, so the cbid and raw CookieConsent value are one click away.
• The lifecycle pushes (CookiebotOnAccept and friends) are captured as dataLayer events with stack-trace source attribution.
• Pushes that happened before DevTools was opened are captured too.

Cookiebot and consent

Cookiebot is the consent source, not a subject of the consent check. Event Watcher reads its state three ways: parsing the CookieConsent cookie (both formats), reading window.Cookiebot.consent.statistics / .marketing / .preferences live, and detecting the lifecycle pushes.

Cookiebot.hasResponse distinguishes "denied" from "not answered yet." Cookiebot's fixed category names map cleanly: statistics to analytics, marketing to marketing, preferences to functional.

Every other captured event is then marked granted, denied, or pre-consent against that state, with violations totaled in the counter.

Common debugging scenarios

• Prior-consent mode is not actually blocking. If statistics is denied but analytics hits still fire, group by Consent Category to list the offenders, often tags added directly in GTM without the Cookiebot template; start with GA4 fires before consent.
• Tags fire before CookiebotOnAccept. The stream's ordering shows whether a pixel's request landed before the accept push. Pre-consent events are flagged explicitly.
• Which script reacted to the consent event? Use which script pushed this dataLayer event and the Script Tree to trace listeners firing off CookiebotOnTagsExecuted.
• Cross-subdomain consent not sticking. Check the cookies section on consentcdn requests to confirm the CookieConsent cookie's domain scope.
• Full pre/post-consent inventory. Run the audit flow in audit all tracking pixels with the banner unanswered, then accepted.