How to Tell if a Website Uses a Cookie Consent Tool (CMP)

To tell if a website uses a cookie consent tool — a consent management platform, or CMP — the banner is your first hint, but to identify the specific tool you open the DevTools Network tab and watch which consent domain loads: cdn.cookielaw.org means OneTrust, consent.cookiebot.com means Cookiebot, and Osano, Termly and Usercentrics each load from their own recognisable domains. Confirm it in the Application tab by reading the consent cookie (OptanonConsent for OneTrust, CookieConsent for Cookiebot) and by inspecting the banner element, which carries provider-specific IDs. This works because a CMP must load early, render a banner and persist the visitor's choice — all observable from the browser. This guide covers every signal, the major platforms, the IAB TCF standard, and the privacy context that makes CMPs worth detecting.

It is a focused companion to how to find out what technology a website uses and pairs closely with how to check if a website uses Google Tag Manager, because a CMP usually governs whether the tags GTM loads are allowed to fire.

What a CMP is, and why it is detectable

A consent management platform is the system behind a cookie banner. When you arrive at a site in a region with consent rules, the CMP presents the choices (accept, reject, manage preferences), records what you decide, stores that decision in a cookie, and signals the site's other scripts — analytics, advertising, personalisation — whether they are allowed to run. The banner you see is just the visible front end; the CMP is the machinery behind it. That machinery is highly detectable because it has to do several observable things on every visit: load a script from the vendor, render a banner with the vendor's own markup, set a consent cookie, and often expose a standard API so other vendors can read the consent state. Each of those is a fingerprint, which is why identifying which CMP a site runs is usually quick.

Signal 1: the loaded script and its domain

The most reliable fingerprint is the script the CMP loads. Open DevTools (F12), go to the Network tab, and reload. The consent platform fetches its code from a recognisable domain:

• OneTrust loads from cdn.cookielaw.org, frequently via a stub script named otSDKStub.js.
• Cookiebot loads from consent.cookiebot.com (its uc.js script).
• Osano loads from cmp.osano.com.
• Termly loads from app.termly.io.
• Usercentrics loads from app.usercentrics.eu (and related domains).

Because consent has to be resolved before trackers fire, the CMP script usually loads early in the page. Seeing one of these domains in the Network tab names the platform almost on its own.

Signal 2: the consent cookie

A CMP's whole job is to remember your choice, so it sets a consent cookie you can read directly. Open the Application tab in DevTools, look under Cookies, and check the keys:

• OneTrust sets OptanonConsent (the detailed consent state) and OptanonAlertBoxClosed (a timestamp marking that the banner was dismissed).
• Cookiebot sets CookieConsent, which encodes the categories the visitor allowed.
• Osano, Termly and Usercentrics each set their own provider-named consent keys.

These cookies are a durable signal: even after the banner is gone, the stored consent record remains, naming the platform that wrote it. They are also a neat illustration of the CMP doing its job — the encoded categories show which kinds of cookie the visitor permitted.

Signal 3: the banner markup

The visible banner carries the vendor's own structure. Right-click the consent banner (or the preferences modal) and choose Inspect, then read the element's id and class:

• OneTrust renders a banner with the id onetrust-banner-sdk and Optanon-prefixed classes, plus a preference centre with its own OneTrust IDs.
• Other CMPs tag their banners with provider-specific containers and class names.

Inspecting the banner is often the fastest visual confirmation, because the markup is right there on screen and the IDs are unmistakable. It also helps when a CMP is white-labelled or themed — the underlying element IDs usually still betray the vendor even when the styling has been customised.

Signal 4: the IAB TCF API (__tcfapi)

Many CMPs implement the IAB Transparency and Consent Framework (TCF), an industry standard for communicating consent to advertising and analytics vendors in a uniform way. A site running a TCF-compatible CMP exposes a global function: open the Console and type typeof window.__tcfapi. If it returns "function", a TCF consent layer is present. (Google's related Additional Consent and the older __cmp function are variations you may also encounter.) This signal does not by itself name the vendor, but it confirms a standards-based consent system is in place — which, combined with the script domain and cookies, completes the picture. The TCF API is especially common on ad-funded and publisher sites that work with many ad vendors.

The signal table

CMP	Script domain	Consent cookie	Banner / API tell
OneTrust	cdn.cookielaw.org (otSDKStub.js)	OptanonConsent, OptanonAlertBoxClosed	#onetrust-banner-sdk, often __tcfapi
Cookiebot	consent.cookiebot.com (uc.js)	CookieConsent	#CybotCookiebotDialog
Osano	cmp.osano.com	Osano consent cookie	Osano banner classes
Termly	app.termly.io	Termly consent key	Termly banner container
Usercentrics	app.usercentrics.eu	Usercentrics consent key	Usercentrics banner, often __tcfapi

A single matching row is usually enough; the script domain plus the consent cookie make it conclusive.

Method 1: View Source

The quickest single check is View Source. Open the page, press Ctrl/Cmd + U, and search for the CMP domains (cookielaw.org, cookiebot, osano, termly, usercentrics). Because the consent script has to load early — before trackers are allowed to run — it is usually placed high in the <head> and appears in the server-rendered source. A source search is therefore a fast first pass that confirms both that a CMP is present and which vendor it is, the same approach that anchors broader technology detection.

Method 2: the DevTools Network and Application tabs

For a thorough read, combine the Network and Application tabs. In Network, reload and watch for the CMP script domain near the top of the waterfall — that confirms the platform is genuinely loading. In Application, open Cookies and read the consent key, which names the vendor and shows the encoded consent state. This pairing is powerful because it captures both the load (the script) and the result (the stored choice). It also lets you watch consent in action: accept or reject in the banner and observe the cookie value change, and watch other tags begin or refrain from firing accordingly — which ties directly to how to check if a website uses Google Tag Manager, since GTM is frequently gated by the CMP.

Method 3: inspect the banner and Console

If the banner is visible, inspect it to read the provider IDs (onetrust-banner-sdk and friends) for an instant visual confirmation. Then drop into the Console and check typeof window.__tcfapi to see whether a TCF consent layer is present. These two quick checks — one on the DOM, one on the API — corroborate the Network and cookie evidence and are handy when a CMP is themed heavily enough that the script domain alone feels ambiguous. The element IDs and the standard API are harder to disguise than surface styling.

The privacy and compliance context

CMPs exist because of privacy law. The EU's GDPR and the ePrivacy Directive (the "cookie law"), the UK's equivalent regime, and a growing patchwork of other regulations require that sites obtain consent before setting non-essential cookies and trackers — and let visitors refuse or withdraw consent as easily as they give it. A CMP is how most sites operationalise that: it blocks non-essential tags until the visitor agrees, records the decision as proof, and provides a preference centre to change it later. So detecting a CMP is partly a read on compliance posture: a site with a well-implemented CMP that genuinely gates trackers behind consent is treating privacy seriously, while a banner that sets cookies regardless of the choice is a weaker (and potentially non-compliant) implementation. Detection tells you which tool is in place; observing whether trackers actually wait for consent tells you how meaningfully it is used.

A worked example

You want to assess how a site handles privacy. On arrival, a cookie banner appears. You right-click it, choose Inspect, and see a container with the id onetrust-banner-sdk and Optanon-prefixed classes — a strong OneTrust signal. You open the Network tab, reload, and confirm a request to cdn.cookielaw.org loading otSDKStub.js. In the Application tab, the cookies include OptanonConsent and OptanonAlertBoxClosed. For completeness, you check the Console: typeof window.__tcfapi returns "function", so OneTrust is running a TCF consent layer. Finally, you watch the Network tab as you click "Reject all" and see that the analytics and ad tags do not fire — the CMP is genuinely gating trackers. The read is clear: this site uses OneTrust as its CMP, integrated with the IAB TCF, and it appears to honour consent before loading non-essential scripts. That is a thorough, defensible picture built entirely from public signals.

Why detecting a CMP matters

Knowing a site's consent tool is useful on several fronts. For privacy and compliance research, the CMP reveals how a site approaches GDPR, ePrivacy and similar rules, and whether it gates trackers behind consent — a meaningful read on data-protection maturity. For sales, especially of privacy, consent or martech software, the incumbent CMP identifies a competitor relationship and a possible switching opportunity. For technographic profiling, the presence and choice of CMP, alongside the analytics and advertising tools it governs, indicates which markets a company serves (a TCF-heavy setup suggests EU ad operations, for example) and how seriously it treats consent. And for an honest audit of a site's own stack, confirming that the CMP actually blocks trackers until consent is given is a practical compliance check, not just a label.

How accurate is CMP detection?

Very accurate for identifying the tool. The script domains, consent cookies and banner IDs are intrinsic to how a CMP works, so naming the platform is reliable across the major vendors, and the __tcfapi check confirms a standards-based layer. The nuance is not in which CMP but in how well it is used: detection tells you the tool is present, but judging whether it genuinely gates non-essential cookies until consent — versus showing a banner while loading trackers anyway — requires watching the Network tab as you accept and reject. So "which CMP does this site run?" is answerable with confidence, while "is its consent implementation actually compliant?" is an inference you draw from observed behaviour. Identify the platform from its fingerprints, then watch it work to judge the implementation.

The workflow

1. Note the banner, then inspect it for provider IDs like onetrust-banner-sdk.
2. Open the Network tab and reload; watch for cdn.cookielaw.org, consent.cookiebot.com and friends.
3. Read the consent cookie in the Application tab (OptanonConsent, CookieConsent).
4. Check the Console for typeof window.__tcfapi to confirm a TCF layer.
5. Watch trackers as you accept/reject to judge whether consent is genuinely enforced.

Go deeper

• The whole stack: how to find out what technology a website uses.
• The tags a CMP governs: how to check if a website uses Google Tag Manager.
• The trackers behind the banner: how to find out what analytics a website uses.
• The cookies on the wire: how to read a website's HTTP response headers.

Want a site's consent tool, trackers and full stack identified automatically? Analyse any site with StackOptic — free, no sign-up.