Didomi

What Is Didomi?

Didomi is a Consent Management Platform (CMP) that helps websites and apps collect, store, and enforce visitor consent for cookies, tracking, and data processing, primarily to comply with privacy regulations such as the EU's GDPR and the ePrivacy Directive. In practice, Didomi powers the consent banner or preference center a visitor sees on first arrival, the interface that asks whether they accept analytics cookies, advertising trackers, and other data uses, and then makes sure the rest of the site honors those choices.

Didomi is a well-established commercial CMP, particularly prominent among European publishers, media groups, and large brands that need a robust, auditable approach to consent. It is one of several CMPs certified within the IAB Europe Transparency and Consent Framework (TCF), the industry standard that coordinates how consent signals are passed to advertising and analytics vendors. That standards alignment is a major reason large ad-funded publishers adopt it.

Didomi is delivered as a software-as-a-service product. Site owners configure their consent notices, vendor lists, and rules in the Didomi console, then embed a small JavaScript snippet (the Didomi Web SDK) on their pages. The platform is a paid service rather than a free library, reflecting its enterprise focus and the compliance, reporting, and vendor-management features it provides.

Didomi is not a browser extension and not something an individual installs in their own browser. It is a publisher-side tool: the site owner adds the Didomi SDK to their pages, and it runs for every visitor. Because that SDK and its supporting scripts load in the browser and set recognizable cookies and global objects, Didomi is straightforward to detect from the outside.

It is worth being precise about what a CMP like Didomi does and does not do. A CMP is the consent layer, it presents choices, records them, and broadcasts the resulting consent state, but it does not itself perform analytics or serve ads. Instead, it gates those other technologies. When a visitor accepts or rejects a category, Didomi communicates that decision to the tag manager, analytics tools, and advertising vendors on the page so they can activate or stay dormant accordingly. Understanding this orchestration role explains why Didomi so often appears alongside, and in front of, a site's analytics and advertising stack rather than in place of it.

How Didomi Works

Didomi's core is a JavaScript SDK that loads early in the page lifecycle. On a visitor's first arrival, the SDK checks whether a valid consent record already exists. If not, it displays the consent notice, a banner or modal generated and styled according to the configuration set in the Didomi console. The visitor's choices (accept all, reject all, or granular per-purpose and per-vendor selections) are then captured and stored.

Consent is persisted in the browser, typically in cookies and local storage, so that returning visitors are not asked again until their consent expires or they reopen the preference center. Within the TCF, Didomi encodes the visitor's choices into a standardized TC string (a compact, encoded consent signal) that advertising and analytics vendors read to determine what they are permitted to do. Didomi also exposes a global JavaScript API so the rest of the site can query consent state and react to it.

The platform acts as an orchestration layer for other technologies. Rather than letting analytics and advertising tags fire unconditionally, a properly integrated site uses Didomi's consent signal, often through a tag manager, to gate when and whether those tags run. When a visitor grants consent for a category, the relevant tags activate; when consent is refused, they remain dormant. Didomi integrates with major tag managers and ad systems to make this enforcement reliable.

On the back end, the Didomi console is where site owners configure everything: the notice's appearance and text, the list of purposes and vendors, geographic targeting rules (so visitors in different regions see appropriate notices), and consent-expiry settings. The platform also provides proof-of-consent storage and reporting, recording when and how consent was given, which is important for demonstrating compliance during audits.

It is useful to trace the full flow from a visitor's perspective. A first-time visitor lands on the page; the Didomi SDK initializes and, finding no stored consent, presents the notice. The visitor reviews the purposes, perhaps allowing analytics but declining personalized advertising, and saves their choices. Didomi writes those choices to cookies and storage, builds the corresponding consent signal, and notifies the page's other technologies. Analytics may now load while advertising personalization stays off. On the visitor's next visit, the stored consent is found, the banner does not reappear, and the same enforcement is applied automatically. At any time the visitor can reopen the preference center, often via a small persistent link or icon, to change their decision, and Didomi updates the stored state and re-broadcasts it.

How to Tell if a Website Uses Didomi

Didomi leaves clear, consistent fingerprints because its SDK and consent artifacts ship to every visitor's browser. StackOptic inspects these signals server-side, and you can confirm them manually with browser tools or curl.

SDK script domain. The strongest signal is a request to Didomi's SDK domains, notably sdk.privacy-center.org (and related Didomi/privacy-center.org hosts). Seeing the page load a script from these domains is close to definitive.

Global JavaScript objects. Didomi injects recognizable globals into the page, most notably window.Didomi (the SDK API) and window.didomiOnReady, along with an internal didomiState object. Finding these in the console is a dependable confirmation.

Consent cookies. Didomi sets distinctive cookies, including didomi_token (which stores the visitor's consent record) and euconsent-v2 (the standardized IAB TCF consent string used by many CMPs). The presence of didomi_token specifically points to Didomi.

DOM markers. The consent notice is rendered into containers with Didomi-specific identifiers and class names, such as elements whose IDs or classes begin with didomi- (for example a didomi-host or didomi-notice container). Inspecting the banner reveals these.

Preference-center link. Many Didomi sites include a persistent link or button to reopen the consent preferences, which is wired to the Didomi API and references Didomi identifiers.

Here is how to check each signal yourself:

Method	What to do	What Didomi reveals
Browser DevTools (Network)	Reload with the Network tab open, filter "didomi" or "privacy-center"	Requests to sdk.privacy-center.org and related Didomi hosts
Browser DevTools (Console)	Type window.Didomi or typeof didomiOnReady	Returns the Didomi SDK object/function when present
Browser DevTools (Application)	Open the Cookies panel	didomi_token and euconsent-v2 cookies
Browser DevTools (Elements)	Inspect the consent banner	Containers with didomi- IDs and classes
curl -s	`curl -s https://example.com	grep -i didomi`
Wappalyzer	Run the extension on the live page	Identifies "Didomi" under consent management / privacy

A quick terminal check is curl -s https://example.com | grep -i "didomi", which often surfaces the SDK reference. In the console, typing window.Didomi is the most direct confirmation, returning the SDK object when Didomi is active. Because consent platforms intersect with analytics and tracking, our guide on how to find out what analytics a website uses pairs well with CMP detection, as does the general methodology in how to find out what technology a website uses.

A few realities of detecting CMPs are worth noting. Because a consent banner is designed to appear immediately and prominently, Didomi is usually easy to spot, the banner itself is a visible clue, and the SDK loads early. Some sites proxy the SDK through their own domain or a tag manager, which can change the script URL, but the global objects (window.Didomi) and the didomi_token cookie are produced by the SDK at runtime and are hard to disguise. The euconsent-v2 cookie, by contrast, is shared across all TCF-compliant CMPs, so on its own it tells you a TCF CMP is in use but not specifically which one; combining it with Didomi-specific markers is what pins down the vendor. As always, the most reliable conclusion comes from several signals together, an SDK reference, a Didomi global, and the didomi_token cookie, rather than any single tell.

Key Features

• Consent notices and preference center. Configurable banners and granular preference interfaces for cookies, purposes, and vendors.
• IAB TCF support. Certified participation in the Transparency and Consent Framework, generating standardized consent signals for ad and analytics partners.
• Geographic targeting. Region-aware rules so visitors see notices appropriate to their jurisdiction (GDPR, CCPA/CPRA, and others).
• Consent enforcement. Integration with tag managers and vendors to gate tags until consent is granted.
• Proof of consent and reporting. Stored records of when and how consent was given, plus analytics on consent rates.
• Cross-platform SDKs. Web SDK plus mobile and connected-TV SDKs for consistent consent across channels.
• Customization and theming. Control over the notice's appearance, copy, and behavior to match brand and legal requirements.

Pros and Cons

Pros

• Robust, audit-ready consent management suited to large publishers and regulated industries.
• Strong IAB TCF support, important for ad-funded sites working with many vendors.
• Flexible geographic targeting to handle multiple privacy regimes from one platform.
• Detailed proof-of-consent and reporting for demonstrating compliance.

Cons

• A paid, enterprise-oriented product rather than a free or lightweight option.
• Adds a JavaScript layer that loads early and can affect perceived performance if misconfigured.
• Correct enforcement requires careful integration with tag managers and vendors.
• More capability and configuration than a small site with minimal tracking typically needs.

Didomi vs Alternatives

Didomi competes with other commercial and freemium consent platforms. The table below highlights where it fits.

Platform	Type	Standout strength	Typical users
Didomi	Commercial CMP (SaaS)	TCF support, audit-grade compliance, multi-channel SDKs	European publishers, media groups, large brands
OneTrust	Commercial privacy suite	Broad privacy/governance platform beyond consent	Large enterprises with wide compliance needs
Cookiebot	Commercial CMP with scanning	Automatic cookie scanning and categorization	SMBs and mid-market sites
Osano	Commercial CMP	Consent plus broader data-privacy tooling	Mid-market and enterprise
Klaro / open-source CMPs	Self-hosted, free	Lightweight, no vendor fees	Developers wanting a simple, free banner

Because a CMP gates the rest of a site's tracking, identifying Didomi is often the first step in mapping a publisher's full analytics and advertising stack. To see how consent and measurement interrelate in detection, compare with how analytics tools surface, covered in our analytics guide above, and with a front-end utility like jQuery that frequently sits alongside a consent banner on older publisher templates.

Use Cases

Didomi is most at home on large, ad-funded, and regulated websites. Media publishers and news groups, especially in Europe, use it to manage consent across many advertising and analytics vendors while satisfying GDPR and ePrivacy obligations. Big consumer brands deploy it to standardize consent across multiple country sites with different legal requirements.

It also fits ecommerce and retail sites that run substantial marketing and remarketing stacks, financial and healthcare organizations with strict data-handling rules, and any business operating across several jurisdictions that needs one platform to handle GDPR, CCPA/CPRA, and other regimes. For privacy and compliance teams, Didomi's proof-of-consent records and reporting are central to audits and regulatory inquiries.

Picture a few representative adopters. A pan-European news publisher with sites in a dozen countries might rely on Didomi to present the right notice in each market, pass standardized consent signals to dozens of advertising partners through the TCF, and keep auditable records of every visitor's choices. A multinational retailer might use Didomi's geographic targeting so EU shoppers see a GDPR-style banner while shoppers in other regions see a notice tuned to local law, all configured from one console. A subscription media brand might use the preference center to let logged-in members fine-tune their data choices over time.

From a technology-research standpoint, detecting Didomi is informative. It signals an organization that takes privacy compliance seriously, typically one large enough to run a substantial advertising or analytics operation that needs gating. For vendors selling adtech, analytics, privacy, or compliance services, that is a meaningful qualifying signal about an account's maturity and regulatory exposure. The broader discipline of reading such signals to prioritize prospects is explored in our guide on using tech-stack data to qualify leads.

Frequently Asked Questions

What is a Consent Management Platform?

A Consent Management Platform (CMP) is a tool that collects and records website visitors' choices about cookies and data processing, then enforces those choices across the site's other technologies. It typically shows a consent banner on first visit, stores the visitor's decisions, and signals analytics and advertising vendors about what they are permitted to do. Didomi is one such CMP, focused on enterprise and publisher use cases with strong support for industry consent standards.

How do I know if a site is using Didomi specifically?

Look for a script loaded from sdk.privacy-center.org, the window.Didomi global object in the console, and a didomi_token cookie in the Application panel. The consent banner's HTML will also contain didomi- IDs and classes. While the euconsent-v2 cookie indicates a TCF CMP is present, it is shared across CMPs, so the Didomi-specific script, globals, and didomi_token cookie are what confirm Didomi in particular.

Is the euconsent-v2 cookie unique to Didomi?

No. The euconsent-v2 cookie holds the standardized IAB TCF consent string and is set by many different TCF-compliant CMPs, not just Didomi. On its own it tells you the site uses a TCF consent platform but not which vendor. To identify Didomi specifically, combine it with Didomi's own markers, the sdk.privacy-center.org script, the window.Didomi object, and the didomi_token cookie.

Does Didomi affect website performance or SEO?

Didomi adds a JavaScript layer that loads early so the consent notice appears before tracking fires, and like any such script it can affect perceived load performance if poorly configured. Properly implemented, the impact is modest. Consent banners do not directly change search rankings, but a slow or layout-shifting banner can hurt user experience and Core Web Vitals, which is why our guide on how to make your website load faster is relevant when tuning any consent integration.

Can a small website use Didomi, or is it only for large publishers?

Didomi is a commercial, enterprise-oriented platform, so it is most common on large publishers, brands, and regulated businesses with substantial tracking and multi-jurisdiction needs. A very small site with minimal cookies may find a lighter or free CMP sufficient. The decision usually comes down to how many vendors a site works with, whether it needs IAB TCF support, and how rigorous its proof-of-consent and reporting requirements are.

Want to detect Didomi and the full stack behind any site in seconds? Try StackOptic at https://stackoptic.com.