Support center » Release notes: consent libraries » Migrate to Cookie Information consent libraries v2.0.0

Migrate to Cookie Information consent libraries v2.0.0

Version 2.0.0 of the frontend libraries is a major internal refactor designed to be a drop-in replacement with few or no breaking changes. Because client setups vary widely, we can’t guarantee full compatibility with every configuration. Our goal is to minimize disruption while modernizing the underlying codebase.

As part of this refactor, we’ve dropped support for some legacy features that no longer follow current best practices. We’ve also fixed several bugs found during development and introduced a few minor features.

Review this guide and compare it with your setup before upgrading. This will help you identify any changes you may need to make.

Wha you can find in this guide

1. How to migrate and what to do afterwards

1.1 Update the library URL in your snippet

To upgrade to v2.0.0, update your snippet to explicitly reference the new version. Changing the script URL is what moves your setup to v2.0.0.

If your snippet currently points to the unversioned URL:

https://policy.app.cookieinformation.com/uc.js

or to a previous versioned URL, such as:

https://policy.app.cookieinformation.com/v1.1.2/uc.js

replace it with the explicit v2.0.0 URL:

https://policy.app.cookieinformation.com/v2.0.0/uc.js

Find the snippet in the <head> section of your site and update the script URL.

This URL pins your setup to v2.0.0. This means you can choose when to upgrade instead of automatically receiving changes from future versions.

If you use Subresource Integrity (SRI): If your snippet includes an integrity attribute, update the hash to match the new v2.0.0 file. An outdated hash will cause the browser to block the script.

Use this hash:

integrity="sha384-2Yw/Q63zzHcZeuy1yyD6Wi1yHBzjQsBnuo9nBHk4toUVFjz6izfPpWazSWb84wWf"

1.2 Choose the sections for your setup

The public contract that most websites depend on is preserved. This includes installation snippets, the consent cookie, the JavaScript API, DOM events, consent categories, and dataLayer, Google Consent Mode, Matomo, and Tealium pushes.

Use the table below to find the sections most relevant to your setup. We still recommend reading the full migration guide.

Your setupWhat to do
You pasted the standard snippet and didn’t add any custom implementation.No action required. Skim section 4, then you’re done.
You use the window.CookieInformation or window.CookieConsent JavaScript API.Read section 5, Breaking changes, and section 6, Behavioral changes.
You’re an ad-tech vendor that relies on the TCF (__tcfapi) or GPP (__gpp) API.Read section 5.3, TCF integration, and section 5.4, GPP integration.
You use our tag templates in Google Tag Manager or another tag manager.Read section 5.5, Tag managers and GTM templates.

2. What stayed the same

We verified that the following behavior is the same in both versions. If your setup relies only on these elements, the migration should be transparent:

  • Installation snippets and detection
    • Consent banner: <script> whose src contains /uc.js and cookieinformation, or id="CookieConsent".
    • Cookie declaration: <script id="CookiePolicy">, with the legacy cd.js or cdreport.js src fallback.
    • All data-* attributes are still read: data-culture, data-gcm-enabled, data-gcm-version, data-tcf-v2-enabled, data-gpp-enabled, data-tealium-enabled, data-consent-sharing-iframe-placement, cs-id, nonce.
  • The first-party consent cookie CookieInformationConsent
    • Same name.
    • Same JSON structure: website_uuid, timestamp, consent_url, consents_approved[], consents_denied[], user_uid, and others.
    • Same path=/; SameSite=Lax; Secure.
    • Same user_uid UUID v4 reuse.
  • Consent categories
    • Same IDs: cookie_cat_necessary, cookie_cat_functional, cookie_cat_statistic, cookie_cat_marketing, cookie_cat_unclassified.
    • cookie_cat_necessary is always true.
  • The consent submission endpoint and payload
    • POST https://consent.app.cookieinformation.com/api/consent
    • Same JSON body.
  • All DOM events
    • See section 7.
    • Same names and { consents: {...} } payloads.
  • DOM hooks used by templates
    • #cookie-information-template-wrapper
    • #updateButton
    • #cicc-template
    • The checkbox selector.
    • The data-category-consent and data-consent-src auto-blocking attributes.
  • dataLayer, Google Consent Mode, Matomo, and Tealium output
    • The category-to-signal mapping is unchanged.
    • The gtag('consent','update', …) payloads for v1 and v2 are unchanged.
    • ads_data_redaction is unchanged.
    • dataLayer.push({ event: <category> }) for each approved category is unchanged.
    • _mtm and utag_data shapes are unchanged.
  • TCF and GPP wire behavior
    • euconsent-v2 cookie name and format.
    • The TC string with service-specific scope.
    • The gppString localStorage key.
    • GVL fetch URLs.
    • CMP ID 162.
    • The __tcfapi and __gpp command sets and iframe or postMessage locators.
  • Cross-domain consent-sharing cookies
    • CookieInformationConfig and CookieInformationConsent_<websiteId> keep the same names.
    • lz-string compression.
    • 365-day expiry.
    • Same iframe filename: cookiesharingiframe.html.

3. Migration in one page for websites with no custom implementation

If you use the standard installation snippets and haven’t written custom JavaScript against our API, there is nothing else to change. Your banner, cookie declaration, auto-blocking, and analytics consent signaling will continue to work.

There are two things to know:

  1. If your cookie declaration snippet still uses the old src-based form without id="CookiePolicy", you’ll now see a one-line console warning asking you to update the snippet. The existing snippet will still work. Copy the latest snippet from your dashboard to remove the warning.
  2. If you use a strict Content-Security-Policy, the new libraries now pass your page’s nonce to the scripts they inject, including the cookie declaration and privacy controls. You may therefore be able to remove unsafe-inline. This is an improvement, not a requirement.

4. Breaking changes

These changes are ordered by how likely they are to affect an existing integration.

4.1 Custom JavaScript API: removed or changed surface

CookieInformation.sendConsent()

  • v1.1.2: Public method
  • v2.0.0: Not exposed

This method is internal. If you called it, switch to submitConsent(), submitAllCategories(), or declineAllCategories().

CookieInformation.config / .websiteUuid

  • v1.1.2: Readable on the object
  • v2.0.0: Not exposed

Read the consent cookie instead if you need the website UUID.

CookieInformation.submitConsent(expirationTime)

  • v1.1.2: Optional expiry argument
  • v2.0.0: submitConsent() – argument ignored

The library now always calculates the expiry. It uses 365 days if all categories are accepted and 14 days otherwise.

You can still override this with cookieInformationCustomConfig.acceptFrequency or declineFrequency. Remove the argument.

CookieInformation.changeCategoryConsentDecision(cat, decision)

  • v1.1.2: Silently ignored incorrect input
  • v2.0.0: Throws for a non-string category, unknown category, or a decision that isn’t boolean or undefined

Pass a valid category ID and true, false, or undefined.

Undocumented _-prefixed internals

Examples include _setCookie, _handleCookieSharing, _setupGoogleConsentMode, manageCookie, and createCustomEvent.

  • v1.1.2: Present on the object
  • v2.0.0: Mostly removed. A small legacy subset remains, including _getVisitorId, _getCookieValue, and _getDataCulture.

These were never part of the supported API. Don’t depend on them.

Legacy IAB TCF v1 support has been removed.

The following are no longer available:

  • data-iab-enabled="true"
  • The old v1 CMP, cmp.js
  • The window.__cmp stub, IABStub.js
  • The #coiConsentBannerIABColumn special case

If you use the legacy v1 flag, move to TCF v2 with data-tcf-v2-enabled. Modern setups are unaffected.

4.2 Stricter error handling

The old library often failed silently. The new library throws errors earlier, which makes broken installations easier to identify.

  • Cookie Declaration: A missing installation snippet or missing #cookie-information-declaration injection target now throws instead of silently doing nothing. injectCookieDeclaration() also no longer returns a boolean.
  • WordPress/YouTube: An invalid youtubeCategorySdk now throws.
  • Cookie auto-blocking: The internal queue drain now has a 500-iteration safety cap.

Action: Correctly installed sites don’t need any changes. If you see a new exception, check for an existing installation problem that the previous version may have hidden.

4.3 TCF integration (__tcfapi)

CMP version changed from 1 to 2.

Every newly issued TC string and every getTCData payload now reports cmpVersion: 2. The CMP ID remains 162.

Vendors or monitoring systems that expect a specific CMP version will see the new value. This is a visible payload change.

agreeToAll(), declineAll(), and saveUserSelections() are now asynchronous and take no arguments.

They return Promise<void> and always submit consent to the server. The old isSDKEnabled branch that skipped submission has been removed.

Action: Remove the arguments. Use await if you need to perform another action after consent is stored. Calls from banner templates that don’t wait for the result are unaffected.

Several methods have been removed from window.CookieInformation.tcfCmp.

  • getDisallowedVendorsLegitimateInterests
  • getOptOutPurposeLegitimateInterests
  • isCookieSet
  • shouldDeclineAllSetAllLegIntPurposesOn
  • Internal handles _tcModel and _storageService
  • Internal setup helpers

getDisallowedVendorsLegitimateInterests and getOptOutPurposeLegitimateInterests were already deprecated and produced console warnings.

All other tcfCmp methods keep their names, signatures, and behavior.

Support for legacy TCF v1 has been removed.

  • The window.__cmp stub has been removed. See section 5.1.
  • The cross-domain iframe handler has been removed: tcf-third-party-handler.js / tcfcmpiframe.html.

The data-tcf-iframe-placement attribute has also been removed. The IAB CMP library now manages the __tcfapiLocator iframe.

The following remain unchanged:

  • TC string construction and service-specific scope.
  • The euconsent-v2 cookie.
  • GVL fetch URLs.
  • Publisher restrictions and configuration.
  • Google additional consent: addtlConsent and gacp in localStorage.
  • Language mapping.
  • The __tcfapi command set and callback shape.

4.4 GPP integration (__gpp)

Default applicable sections changed from [-1] to [].

When a publisher has no GPP configuration, applicableSections reported by __gpp('ping') changes from [-1], meaning ‘not applicable’, to an empty array.

Downstream vendors that use this value in their logic may behave differently.

The GPP stub phase now follows the specification and uses callbacks only.

During the brief period before the full GPP script loads, __gpp('ping') no longer returns a value synchronously. You need to use the callback.

The stub’s advertised supportedAPIs and cmpId also differ during this phase. Fully specification-compliant __gpp callers are unaffected.

The following remain unchanged:

  • CMP ID 162.
  • Loaded section set: 7:usnat, 8:usca, 10:usco, 12:usct.
  • The gppString localStorage key and value.
  • The __gpp iframe and postMessage locator.

4.5 Tag managers and GTM templates

The internal CookieInformationConsentForGCMTemplate window event is no longer dispatched.

This event was used by our own GTM Consent Mode tag template, which is versioned together with the library.

The supported public hook, CookieInformation.addCustomEventListenerForGTMConsentModeTemplate(cb), still exists. It now listens to CookieInformationConsentSubmitted and the internal _CookieInformationCiccLoaded.

Action: If you manually added a listener for CookieInformationConsentForGCMTemplate, switch to addCustomEventListenerForGTMConsentModeTemplate or listen for CookieInformationConsentGiven.

The GTM dataLayer.push({ event: <category> }), Matomo _mtm, and Google Consent Mode gtag payloads remain unchanged. See section 3.

5. Behavioral changes

These changes aren’t breaking, but you may notice them in some setups.

Cookie auto-blocking

Cookie auto-blocking now removes unwanted cookies by iterating through the auto-blocking list (CABL) instead of scanning document.cookie.

Processing now waits until both the list has loaded and the first CookieInformationConsentGiven event has fired.

For most setups, this works the same way. Cookies set on unusual paths or subdomains may be handled slightly differently. Test this behavior if you rely on removing specific cookies.

Consent-sharing cookies

Consent-sharing cookies on the shared domain are now always written with SameSite=None; Secure.

These cookies require HTTPS. Cross-domain sharing tested over plain HTTP will no longer set the cookie.

Malformed configuration now recovers automatically.

A corrupted consent-sharing configuration cookie or invalid cookieInformationCustomConfig.GPP is now validated and reset to its default value with a console warning. Previously, it could throw an error during the flow.

6. Events reference

All nine existing public custom events keep the same names and payloads. Continue to listen for them as before:

EventPayloadFired when
CookieInformationAPIReadynullwindow.CookieInformation is ready and isCookieInformationAPIReady becomes true.
CookieInformationConsentGiven{ consents }Consent is submitted or restored from the cookie.
CookieInformationConsentSubmitted{ consents }Decisions are sent to the server.
CookieInformationAcceptAll{ consents }The visitor selects Accept all.
CookieInformationRejectAll{ consents }The visitor selects Reject all.
CookieInformationSaveSelectedChoices{ consents }The visitor selects Save settings using #updateButton.
CookieInformationFormShownnullThe banner is shown.
CookieInformationFormRefreshednullCookieConsent.show() or .renew() is called.
CookieInformationStorageClearednull‘Push for consent’ clears Cookie Information storage.

New in v2.0.0: CookieInformationFormHidden with a null payload is dispatched when the banner is hidden.

There are also internal, underscore-prefixed coordination events:

  • _CookieInformationCiccLoaded
  • _CookieInformationTcfLibraryLoaded
  • _CookieInformationGppLibraryLoaded

Don’t depend on these internal events.

7. New capabilities

You can adopt the following capabilities if they’re useful for your integration:

  • CookieInformation.isGoogleConsentModeEnabled() is a new public method that returns the Google Consent Mode state. Use it instead of the legacy CookieInformation._isGoogleConsentModeEnabled().
  • window.CookieInformationInternalApi is a new global that exposes internal service instances for use between Cookie Information libraries. It isn’t a supported public API, so don’t build against it.
  • window.CookieInformation.version is now populated from the build version.
  • CSP nonce propagation: Injected scripts now carry your page’s nonce. See section 4.

8. Pre-migration checklist

Before you roll out v2.0.0 to production, check your integration:

  • [ ] You don’t call CookieInformation.sendConsent, .injectCategoriesConsent, .config, or .websiteUuid. See section 5.1.
  • [ ] Any submitConsent(expirationTime) calls no longer pass the argument. See section 5.1.
  • [ ] changeCategoryConsentDecision() is called only with valid categories and true, false, or undefined decisions. See section 5.1.
  • [ ] You don’t use the legacy data-iab-enabled TCF v1 flag. See sections 5.1 and 5.3.
  • [ ] TCF vendors: Your integration accepts cmpVersion: 2, doesn’t call removed tcfCmp methods, and doesn’t pass arguments to agreeToAll() or declineAll(). See section 5.3.
  • [ ] GPP: Your vendors accept applicableSections:[] when GPP isn’t configured, and your __gpp stub calls use callbacks. See section 5.4.
  • [ ] GTM template: You use addCustomEventListenerForGTMConsentModeTemplate or CookieInformationConsentGiven, not the internal CookieInformationConsentForGCMTemplate event. See section 5.5.
  • [ ] Your cookie declaration snippet uses id="CookiePolicy" to avoid the deprecation warning. See section 4.

Was this article helpful?