Category: CMP Implementation
CMP JavaScript Object
Also known as: CMP JS API, __cmp, CMP JavaScript API
Simply put
A CMP JavaScript object is a piece of code that a consent management platform (CMP) places on a website so that other scripts on the page can find out whether a user has given or refused consent for cookies and similar technologies. Websites and vendor scripts call this object to check a person's consent choices before, for example, loading analytics or advertising tools. It is a technical building block that helps carry out consent decisions, but it does not by itself determine whether those decisions are legally valid.
Formal definition
In JavaScript, an object is a collection of properties, each an association between a key and a value; a CMP JavaScript object is such an object (or an associated global function) exposed by a consent management platform to communicate consent state and configuration to on-page and in-frame callers. Under the IAB Transparency and Consent Framework (TCF), the API historically surfaced a global function (for example, one named __cmp) that in-frame callers could check for, returning objects describing the CMP's loading status, configuration, and the user's consent for purposes and vendors; individual CMP vendors also publish their own public methods for enabling or retrieving consent for categories, hosts, and vendors. The object mediates the technical execution of consent signals but does not establish the legal validity of consent, which under EU law generally must be freely given, specific, informed, and unambiguous; the specific methods, property names, and behaviors vary by CMP implementation and by TCF version, and are out of scope for this general definition.
Why it matters
The CMP JavaScript object is the practical mechanism by which a website's consent decisions are actually enforced on the page. When a user accepts or refuses cookies through a consent banner, that choice only has an effect if the scripts that load analytics, advertising, or functional tools actually check the consent state before firing. The CMP JavaScript object is what those scripts query. If it is misconfigured, or if vendor scripts do not consult it, tracking technologies can load regardless of the user's stated preference, creating a gap between the consent recorded and the behavior of the site.
Who it's relevant to
Web developers and engineers
Developers are the primary audience for the CMP JavaScript object, since they use its methods to gate the loading of analytics, advertising, and other scripts based on consent state. Because method names, property names, and behaviors differ between CMP vendors and TCF versions, developers generally need to work from the specific CMP's documentation. Correct integration is what turns a recorded consent choice into actual on-page behavior.
Privacy officers and data protection professionals
For privacy teams, the CMP JavaScript object matters because it is where a site's stated consent policy meets its technical execution. It is worth understanding that the object mediates the carrying out of consent signals but does not by itself establish whether consent is legally valid, under EU law, consent generally must be freely given, specific, informed, and unambiguous. Verifying that the object is actually consulted before tags fire is a practical part of assessing whether a site behaves consistently with its consent notice.
Legal and compliance counsel
Counsel advising on cookie compliance should recognize that a CMP and its JavaScript object are tools that support compliance rather than guarantee it. The presence of a well-formed object does not resolve legal questions about whether valid consent was obtained, and obligations differ across jurisdictions, for example between the EU, the UK, and individual US states. Counsel may find it useful to confirm that technical enforcement aligns with the legal basis relied upon, but the object itself does not determine that basis.
Marketing and advertising technology teams
Marketing and adtech teams that deploy tags, pixels, SDKs, and vendor scripts rely on the CMP JavaScript object, particularly under the TCF, to determine whether a given vendor or purpose has consent before activating. Understanding how the object surfaces consent for specific vendors and purposes helps these teams ensure that tracking technologies respect user choices, while recognizing that similar rules apply to non-cookie technologies such as pixels and local storage.
Inside CMP JavaScript Object
Consent State Accessor
A method or property exposed by the CMP JavaScript object that returns the current user's consent status, typically broken down by cookie category (such as strictly necessary, analytics, advertising, and functional) or by specific purposes and vendors. Scripts query this before firing tags that place or access information on the user's device.
Event Listeners and Callbacks
Hooks that allow other scripts to subscribe to consent changes, so that tags can be activated or blocked in response to the user granting, withdrawing, or updating consent. This supports the dynamic nature of consent, which under EU frameworks must remain as easy to withdraw as to give.
TCF API Surface (where applicable)
When the CMP participates in the IAB Transparency and Consent Framework, the object may implement the standardized __tcfapi command interface, exposing the TC string and vendor/purpose signals to compatible tags. This is one specific framework and is not the only way a CMP object can be structured.
Configuration and Metadata
Properties describing the CMP's setup, such as the categories defined, the geographic or regulatory scope applied, language, and identifiers used for consent logging. These help align the client-side behavior with the record-keeping obligations under applicable law.
Consent Retrieval and Persistence Interface
Methods that read or reference where consent has been stored (for example a first-party cookie or local storage entry) so the object can reflect a returning visitor's prior choices without re-prompting unnecessarily.
Common questions
Answers to the questions practitioners most commonly ask about CMP JavaScript Object.
Does deploying a CMP JavaScript object on my site make my cookie consent compliant?
No. A CMP JavaScript object is a technical mechanism that surfaces consent notices, captures user choices, and exposes an API for other scripts to check consent state. It supports compliance but does not guarantee it. Whether your implementation meets legal requirements depends on factors the object itself cannot enforce, such as whether consent is freely given, specific, informed, and unambiguous under the GDPR in the EU, whether non-essential tags are genuinely blocked before consent, how records are kept, and how the setup maps to the different obligations across the EU, UK, and individual US states. The object is a tool; legal judgment and correct configuration remain necessary.
If the CMP JavaScript object reports that consent is granted, does that satisfy both the ePrivacy rules and the GDPR?
Not automatically. In most EU jurisdictions the placing of and access to information on a user's device is governed by the ePrivacy Directive as implemented nationally, while any subsequent processing of personal data is governed by the GDPR. A single consent state returned by the CMP object may be used to inform both, but the two regimes have distinct requirements, and a consent signal captured for one purpose does not necessarily meet the standard for the other. You should confirm that the consent the object records is specific enough for each purpose and legal basis rather than treating one returned value as covering everything.
How do other scripts on my page read consent state from the CMP JavaScript object?
Typically the CMP exposes a global function or API on the page that other scripts can call to query the current consent state, often returning which purposes or vendors the user has accepted or rejected. Where a CMP participates in the IAB Transparency and Consent Framework, it generally implements a standardized command interface so that participating vendors can request consent data in a consistent format. Implementations vary between CMPs, so you should consult the specific CMP's documentation for the exact method names, parameters, and returned structure rather than assuming a universal interface.
Should tags fire before the CMP JavaScript object has loaded and returned a consent decision?
Generally, non-essential tags such as analytics and advertising should not fire before a valid consent decision is available, because prior consent is typically required for those categories under EU law. In practice this means gating or blocking those scripts until the CMP object has loaded and reported the relevant consent state, or using the CMP's callback or event mechanism to release tags only after consent is confirmed. Strictly necessary or essential functionality is generally exempt from this gating. How you implement the blocking depends on your tag management setup, and you should verify that tags are genuinely prevented from executing rather than merely hidden.
How can I use the CMP JavaScript object to respond to changes when a user updates their preferences?
Many CMPs allow scripts to register a listener or callback that is invoked when the consent state changes, so that dependent scripts can start or stop processing accordingly. This is relevant because users can typically withdraw or amend consent at any time, and your site should reflect that change without requiring a full reload where feasible. The available event names, subscription methods, and the timing of callbacks differ between CMPs, so refer to the specific product's API documentation, and test that withdrawal actually stops the relevant tags rather than only updating the stored value.
Does the CMP JavaScript object handle consent logging and record-keeping on its own?
The object often provides access to the current consent state and may expose an encoded representation of the user's choices, but consent logging and record-keeping are separate concerns that depend on how the CMP is configured and how your systems store the data. Maintaining records of consent may be required to demonstrate that valid consent was obtained, and this generally involves persisting the choices, their scope, and relevant context in line with your obligations. You should confirm what your specific CMP records by default, where those records are stored, and whether that meets the accountability expectations applicable in your jurisdiction, rather than assuming the client-side object alone is sufficient.
Common misconceptions
If the CMP JavaScript object reports consent, any tag can fire and the site is automatically compliant.
The object communicates a consent state, but it does not itself guarantee compliance. Tags must actually respect that state, the consent must have been validly collected (freely given, specific, informed, and unambiguous under the GDPR in the EU), and the underlying processing must have a lawful basis. The tool supports compliance but does not replace legal judgment.
The CMP object only governs cookies.
The consent signals it carries generally apply to functionally similar technologies as well, such as tracking pixels, local storage, SDKs, and fingerprinting, because in most EU jurisdictions the rules on placing or accessing information on a device extend beyond literal cookies. Scripts using these technologies should check the same consent state.
A single consent state from the object applies the same way in every jurisdiction.
Consent obligations differ between the EU, the UK, and individual US states such as California under the CCPA and CPRA, with many US regimes relying on opt-out rather than opt-in. A well-configured object may expose different signals depending on the applicable regime, and practitioners should not treat one jurisdiction's model as universal.
Best practices
Gate the loading and execution of non-essential tags (analytics, advertising, functional) on the object's consent state, rather than firing them before checking, since prior consent is typically required in most EU jurisdictions for anything beyond strictly necessary technologies.
Use the object's event listeners so that consent withdrawal or updates immediately stop the relevant processing, keeping withdrawal as easy as the original grant.
Apply the consent checks consistently to pixels, SDKs, local storage, and fingerprinting, not just literal cookies, so functionally equivalent technologies are treated under the same rules.
Verify that the object's exposed signals align with the applicable regulatory scope (for example opt-in models in the EU and UK versus opt-out models under US state laws), and configure geographic targeting rather than assuming one model fits all users.
Where the TCF API is implemented, confirm downstream vendors correctly read and honor the TC string, and do not assume TCF participation alone resolves all consent obligations.
Ensure consent choices surfaced by the object are also recorded in your consent logs to support record-keeping obligations, and treat the object as a support tool that still requires independent legal review of your overall consent practices.
