Debug Didomi in Chrome DevTools

What Didomi traffic looks like

Didomi's web SDK loads from its privacy-center hosts, while the consent state lives in a Base64 token cookie and on window.

Endpoint pattern

sdk.privacy-center.org: typically loader.js keyed by the site's API key, which pulls the per-site configuration and notice assets; consent reads and writes go to api.privacy-center.org (events, consent syncs, and the token exchange that keeps state consistent across a brand's domains)

Cookies

didomi_token: Base64-encoded JSON with a purposes.consent object holding enabled and disabled arrays of purpose IDs; IDs are partly site-specific, mixing standard slugs like analytics or advertising with custom ones, the main thing to know before parsing it by hand

Data layer objects

window.Didomi.getCurrentUserStatus() for runtime state; the GTM integration pushes didomi-ready, didomi-consent, and didomi-consent-changed carrying comma-separated purpose lists in didomiPurposesEnabled / didomiPurposesDisabled (older equivalent: didomiPurposesConsent / didomiPurposesConsentDenied)

Debugging Didomi with Event Watcher

• Detected from its privacy-center.org traffic, with each request badged in the live stream.
• No dedicated payload parser: you work from the raw request with parsed query and body parameters plus cookies sent and set per event, which puts the raw didomi_token one click away.
• The didomi-* dataLayer pushes are captured with stack-trace source attribution.
• Pushes that fired before DevTools opened are captured too.

Didomi and consent

Didomi is a source of consent state, not a subject of the consent check. The extension reads it three ways: decoding the didomi_token cookie, calling window.Didomi.getCurrentUserStatus(), and parsing the purpose lists on the didomi-consent and didomi-ready pushes.

Because purpose IDs vary by site, Didomi has no fixed category table. Event Watcher keyword-matches purpose names to the unified analytics/marketing/functional categories, claiming only the ones it can map confidently rather than defaulting unknowns to denied.

Every other captured event is then marked granted, denied, or pre-consent against that resolved state.

Common debugging scenarios

• Custom purpose IDs don't map anywhere. Decode the didomi_token from the cookies section (or read the push payload) to see the exact IDs in enabled / disabled, the usual culprit when downstream consent logic silently does nothing.
• Analytics fires before the notice is answered. Pre-consent events are flagged and totaled in the violations counter; see GA4 fires before consent.
• Consent Mode interplay. Didomi ships a Google Consent Mode integration. Watch the consent command pushes alongside didomi-consent-changed and compare with debugging Consent Mode v2; the Google Consent Mode page covers the wire side.
• Which script reacted to didomi-consent-changed? Use the Script Tree and which script pushed this dataLayer event to trace listeners.
• Cross-domain consent drift. Compare api.privacy-center.org sync calls and the token cookie across a brand's domains to confirm the shared-consent setup actually round-trips.