You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
IAB Europe Transparency & Consent Framework
Final v.2.2 May 2023
Table of Contents
| Date | Version | Comments |
|---|---|---|
| Feb 2024 | 2.2 | Deprecated the gdpr_pd macro, and added the field 'environments' to the CMP JSON. |
| May 2023 | 2.2 | Update to further strengthen the TCF as a standard in the industry: revised purpose names and descriptions, introduced retention periods for all purposes, removed legitimate interest for purposes 3 to 6, the introduction of data categories used in conjunction with the purposes, support for legitimate interest claim urls, adding support for localized policy urls and introducing a more robust vendor compliance program. |
| June 2022 | 2.1 | Update of the Global Vendor List JSON Object example regarding the filename in deviceStorageDisclosureUrl |
| Feb 2022 | 2.1 | Move the current vendor fields relating to the Planet 49 ruling from the existing Device Storage Access & Disclosure tech spec to this core spec |
| Dec 2021 | 2.0 | Update of Created and LastUpdated to have the same value corresponding to the day-level timestamp of when the TC String was last updated |
| Sept 2021 | 2.0 | Deprecation of Global Scope, OOB and 'euconsent-v2' cookie associated with the consensu.org domain |
| August 2021 | 2.0 | Added optional use of DisclosedVendor segment in the context of storing service-level TC Strings |
| July 2021 | 2.0 | Highlight the deprecation of Global Scope, OOB and 'euconsent-v2' cookie associated with the consensu.org domain |
| May 2021 | 2.0 | Special Purpose only vendors transparency clarification |
| December 2020 | 2.0 | Domain name change for GVL resources |
| May 2020 | 2.0 | Updated to clarify questions on RestrictionType cases |
| December 2019 | 2.0 | Updated with global cookie support notes, Updated macros to be upper case |
| August 2019 | 2.0 | Version 2.0 released to the public |
| April 2019 | 2.0 | Released for public comment |
| April 2018 | 1.1 | First version released to the public |
This document is one of the IAB Europe Transparency and Consent Framework Specifications. It defines the technical implementation of the structure and encoding for a Transparency and Consent String (TC String), and the format for a Global Vendor List (GVL) maintained by IAB Europe. The TC String is a technical component of the IAB Europe Transparency & Consent Framework (TCF).
The General Data Protection Regulation (GDPR) requires a high level of accountability for how personal data is processed. While important to all parties in the digital advertising ecosystem, implementation of the GDPR came with heavy technical challenges.
The GDPR requires, amongst others, a legal basis for such processing. The two most relevant legal bases are the consent of the user to the processing of their personal data, and the legitimate interests of the controller or a third party to the processing of a user’s personal data, provided that the interests and fundamental rights of the user are not overriding. Both legal bases require the provision of disclosures to ensure transparency, and the opportunity for user choice either through the user’s consent to the processing of their personal data before the processing starts if the legal basis is consent, or through the user’s objection to the processing of their personal data after the processing starts if the legal basis is a legitimate interest. Under the GDPR, controllers are required to create and maintain records of compliance, including, but not limited to user consent records. This warrants clear standards for a common technical solution for all affected parties and policies to govern how that solution is used.
IAB Europe established the TCF to support compliance with the GDPR in the context of digital advertising. This framework is built on four components: a Global Vendor List (GVL), a Transparency and Consent String (TC String), an API for Consent Management Providers (CMPs) to create and process the TC String, and the Policies that govern how the TCF is used.
Prescribed use of the TCF may support compliance with the GDPR, but the real benefit to the digital advertising ecosystem is a safer Internet for consumers, and more reliable data for brands and publishers. As adoption of the TCF increases, compliance becomes more scalable and data becomes more meaningful.
To participate in the use of the TCF, vendors must make a public attestation of compliance with the Policies for using it. Register as a vendor and be listed in the GVL to signal your status having transparency and consent established for your online services. To play a role in creating a TC String for signaling status on transparency and user consent, sign up with IAB Europe to become a CMP. CMPs must follow technical standards provided in this document for creating TC Strings in compliance with TCF Policies. They must also follow technical standards guidance for using the CMP API specified in this document to receive and process information provided in a TC String.
Engineers for a registered CMP can use this document to design or update a solution for generating a TC String. In particular, first parties (content publishers, advertisers, and other suppliers of online services) and third-party (vendors for data-driven services) organisations should be familiar with the purpose and scope of a TC String as well as what information it provides, and support its implementation.
IAB Europe Transparency & Consent Framework (TCF) has a simple objective to help all parties in the digital advertising chain ensure that they comply with the EU’s General Data Protection Regulation and ePrivacy Directive when processing personal data or accessing and/or storing information on a user’s device, such as cookies, advertising identifiers, device identifiers and other tracking technologies. IAB Tech Lab stewards the development of these technical specifications.
Resources including policy FAQ, Global Vendor List, and CMP List can be found at iabeurope.eu/tcf.
IAB Europe Transparency and Consent Framework technical specifications governed by the IAB Tech Lab is licensed under a Creative Commons Attribution 3.0 License. To view a copy of this license, visit creativecommons.org/licenses/by/3.0/ or write to Creative Commons, 171 Second Street, Suite 300, San Francisco, CA 94105, USA.
THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MATERIALS OR SERVICES PROVIDED TO OR USED BY YOU HEREUNDER (THE “PRODUCTS AND SERVICES”) ARE PROVIDED “AS IS” AND “AS AVAILABLE,” AND IAB TECHNOLOGY LABORATORY, INC. (“TECH LAB”) MAKES NO WARRANTY WITH RESPECT TO THE SAME AND HEREBY DISCLAIMS ANY AND ALL EXPRESS, IMPLIED, OR STATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AVAILABILITY, ERROR-FREE OR UNINTERRUPTED OPERATION, AND ANY WARRANTIES ARISING FROM A COURSE OF DEALING, COURSE OF PERFORMANCE, OR USAGE OF TRADE. TO THE EXTENT THAT TECH LAB MAY NOT AS A MATTER OF APPLICABLE LAW DISCLAIM ANY IMPLIED WARRANTY, THE SCOPE AND DURATION OF SUCH WARRANTY WILL BE THE MINIMUM PERMITTED UNDER SUCH LAW. THE PRODUCTS AND SERVICES DO NOT CONSTITUTE BUSINESS OR LEGAL ADVICE. TECH LAB DOES NOT WARRANT THAT THE PRODUCTS AND SERVICES PROVIDED TO OR USED BY YOU HEREUNDER SHALL CAUSE YOU AND/OR YOUR PRODUCTS OR SERVICES TO BE IN COMPLIANCE WITH ANY APPLICABLE LAWS, REGULATIONS, OR SELF-REGULATORY FRAMEWORKS, AND YOU ARE SOLELY RESPONSIBLE FOR COMPLIANCE WITH THE SAME.
The IAB Technology Laboratory (Tech Lab) is a non-profit consortium that engages a member community globally to develop foundational technology and standards that enable growth and trust in the digital media ecosystem.. Comprised of digital publishers, ad technology firms, agencies, marketers, and other member companies, IAB Tech Lab focuses on improving the digital advertising supply chain, measurement, and consumer experiences, while promoting responsible use of data. Its work includes the OpenRTB real-time bidding protocol, ads.txt anti-fraud specification, Open Measurement SDK for viewability and verification, VAST video specification, and DigiTrust identity service. Board members include ExtremeReach, Facebook, Google, GroupM, Hearst Digital Media, Index Exchange, Integral Ad Science, LinkedIn, LiveRamp, MediaMath, Microsoft, Oracle Data Cloud, Pandora, PubMatic, Quantcast, Rakuten Marketing, Telaria, The Trade Desk, Verizon Media Group, Xandr, and Yahoo! Japan. Established in 2014, the IAB Tech Lab is headquartered in New York City with staff in San Francisco, Seattle, and London. Learn more at https://www.iabtechlab.com.
IAB Europe is the European-level association for the digital marketing and advertising ecosystem. Through its membership of National IABs and media, technology and marketing companies, its mission is to lead political representation and promote industry collaboration to deliver frameworks, standards and industry programmes that enable business to thrive in the European market.
Learn more about IAB Europe here: https://www.iabeurope.eu/
In the TCF, a TC String is used to encapsulate relevant details about how transparency and consent was established and encoded as it applies for each of the Purposes, Special Purposes, Features, and Special Features defined by the Policies and for participating Vendors. This document specifies how that string must be formatted, who should use it, and how it must be used.
Regarding specific definitions as they relate to TCF Policies and the technology described in this document, please refer to IAB Europe Transparency and Consent Framework Policies located at the following link:
A TC String’s primary purpose is to encapsulate and encode all the information disclosed to a user and the expression of their preferences for their personal data processing under the GDPR. Using a Consent Management Platform (CMP), the information is captured into an encoded and compact HTTP-transferable string. This string enables communication of transparency and consent information to entities, or “vendors”, that process a user's personal data. Vendors decode a TC String to determine whether they have the necessary legal bases to process a user's personal data for their purposes. The concise string data format enables a CMP to persist and retrieve a user’s preferences any time they're needed as well as transfer that information to any vendors who need it.
A TC String contains the following information:
A Transparency & Consent String may only be created by an IAB Europe TCF registered CMP using its assigned CMP ID number in accordance with the Policies. Vendors or any other third-party service providers must neither create nor alter TC Strings. These and other requirements are articulated in the Policies to which all parties including CMPs, Publishers, and Vendors, are bound.
A TC String that contains positive consent signals must not be created before clear affirmative action is taken by a user that unambiguously signifies that user’s consent. However, a TC String may be created with only legitimate interest establishment signals providing that legitimate interest transparency has been established in accordance with the Policies.
CMPs must operate in a service-specific or group-specific configuration. A TC String in this context is applicable only on a service or group of services, for example the site(s) or app(s) on which it is running. One is created for every user on a given site/app or group of sites/apps. They may contain Publisher restrictions and a Publisher TC segment when returned by the CMP API.
The TCF Policy previously allowed legal bases in the Framework to be established with global scope, which means a legal basis is not only applicable on the service or group of services (service-specific and group-specific scopes) where it is obtained and managed, but all services implementing global scope preferences. In the context of global scope, TC Strings were stored in a 3rd party cookie associated with the “consensu.org” domain that enabled Consent Management Providers (CMPs) to read the “TC strings from their subdomains [cmp-name].mgr.consensu.org across different services. Deprecation of global-scope support was announced on June 22nd 2021. Alongside the deprecation of global scope, support for Out-of-Band (OOB)—which refers to instances where a legal basis has not been established using the TCF in a global-scope context—was also deprecated. Since Sept 1st 2021, TC strings established with global-scope are considered invalid.
Version 2.0 of the Framework introduced the ability for publishers to signal restrictions on how vendors may process personal data. Restrictions can be of two types:
Publisher restrictions are custom requirements specified by a publisher. In order for vendors to determine if processing is permissible at all for a specific purpose or which legal basis is applicable (in case they signaled flexibility in the GVL) restrictions must be respected.
For the avoidance of doubt:
In case a vendor has declared flexibility for a purpose and there is no legal basis restriction signal it must always apply the default legal basis under which the purpose was registered aside from being registered as flexible. That means if a vendor declared a purpose as legitimate interest and also declared that purpose as flexible it may not apply a "consent" signal without a legal basis restriction signal to require consent.
When a creative is rendered, it may contain a number of pixels under tags. For example, which fires an HTTP GET request from the browser to Vendor A’s domain.
Since the pixel is in an tag without the ability to execute JavaScript, the CMP API cannot be used to obtain the TC String. All parties in the ad supply chain who transact using URLs must add a macro in their URLs where the TC String is inserted. Any caller with access to the applicable TC String must insert it within a URL containing the macro $ where XXXXX is the numeric Vendor ID of the vendor receiving the TC string.
For example, for Vendor A with ID 123 to receive a TC String, an image URL must include a key-value pair with the URL parameter and macro gdpr_consent=$ .
The resulting URL is:
If the TC String is: COvFyGBOvFyGBAbAAAENAPCAAOAAAAAAAAAAAEEUACCKAAA.IFoEUQQgAIQwgIwQABAEAAAAOIAACAIAAAAQAIAgEAACEAAAAAgAQBAAAAAAAGBAAgAAAAAAAFAAECAAAgAAQARAEQAAAAAJAAIAAgAAAYQEAAAQmAgBC3ZAYzUw
Then the caller replaces the macro in the URL with the actual TC String so that the originally placed pixel containing the macro is modified as follows when making the call to the specified server.
TC Strings must always be propagated as is, and not modified. Additional URLs in the supply chain are addressed the same way with remaining vendors.
The available URL parameters and macros to relay information down the supply chain are listed in the following section.
Services that are called using a URL from the user's browser, like cookie staplers, user id associators, and tracking pixels (the 'callee') are passed as macros within the URL and formatted as:
&url_parameter=$
The supported URL parameters and the corresponding macros are defined below:
| URL parameter | Corresponding Macro | Representation in URL |
| gdpr | GDPR | &gdpr=$ |
| gdpr_consent | GDPR_CONSENT_XXXXX |
( XXXXX is numeric Vendor ID - the ID of the vendor on the GVL who is expecting this URL call)
E.g. &gdpr_consent=$ for Vendor ID 123.
The service making the call must replace the macros with appropriate values described in the table below. For macro $ , the service making the call must also check that the macro name contains a valid Vendor ID before replacing the macro. The creator of the URL should ensure these parameters are added only once, and are passed to services which are expecting them and can handle them properly.
| Macro | possible values | purpose |
| $ | 0 / 1 | 0 GDPR does not apply; 1 GDPR applies. |
| $ | URL-safe base64-encoded Transparency & Consent string. Only meaningful if gdpr=1 | Encodes the TC string, as obtained from the CMP JS API or OpenRTB. |
Note: other personal data, like IP addresses or callee cookies, may be passed as part of the request, and the gdpr and gdpr_consent_xxxxx is used by the callee to determine whether an identifier cookie or other personal data can be set and/or used.
Policies require consent for Purpose 1 to store and/or access information on a device “where such consent is necessary” leaving the responsibility to publishers and vendors to determine if consent in those jurisdictions is required or not.
If a publisher is operating a CMP within a jurisdiction that does not require consent to store and/or access information on a device and, therefore, does not ask for consent on behalf of a vendor for a purpose 1, the CMP will write the corresponding bit in the PurposesConsent field to 0 . Even though it is valid within that jurisdiction to not request consent for Purpose 1, a vendor would interpret that 0 as a “no consent” signal and have no way of knowing that consent was not required in the jurisdiction in which the publisher operates. This lack of transparency would, ultimately, cause losses in ad revenue for that publisher.
To accommodate cases where Purpose 1 is governed differently for consent depending on the jurisdiction, a TC String is transparent about the publisher’s operating governance and whether or not Purpose 1 was disclosed to a user. The vendor can then use these details to make a determination about whether they have sufficient legal bases for personal data processing in that given context. To support this, there are two fields in a TC String: PublisherCC, which represents the publisher’s country code and a flag for whether any disclosure has been offered on Purpose 1 named PurposeOneTreatment. Details for each field are listed among the fields used in the TC String.
The Created and LastUpdated fields previously corresponded to decisecond timestamps. Considering practical guidance from DPAs relating to the the various means that can be employed by data controllers to provide evidence of the consent obtained and its validity and the limited relevance of the Created field for publishers and their CMPs to fulfill the requirements of remaining users of their choices, as appropriate and at least every 13 months, the Created and LastUpdated fields have been updated to have the same value corresponding to the day-level timestamp of when the TC String was last updated.
In order to strengthen the TCF as a standard within the industry it was decided with version 2.2 to prohibit reliance on Legitimate Interest for purpose 3 (create a personalised ads profile), purpose 4 (select personalised ads), purpose 5 (create a personalised content profile) and purpose 6 (select personalised content).
The following details provide information on creating, storing, and managing a TC String.
In version 2 of the TCF Specifications, the storage mechanism used for service-specific and group-specific TC Strings is up to a CMP, including any non-cookie storage mechanism.
The IAB Europe Transparency & Consent Framework Policies defines Purposes, Special Purposes, Features, Special Features, and Stacks (groupings of Purposes and/or Special Features). You can reference the details of these purposes and features in the document found at the following URL:
With the release of TCF v2.2, the policy version has been incremented to version 4. Post 30 September 2023 a TC String created with a policy version set to smaller than 4 will be deemed invalid. TC Strings with policy version 3 created until 30 September 2023 may still be returned by the CMP API post 30 September 2023"
Post 30 September 2020, v1.x strings were considered invalid. If a CMP encounters a situation where both a v1.x string and a v2.0 string are erroneously present simultaneously, the CMP should remove the v1.x string to ensure that there is only one source of truth for consumers of the string.
Note: TCF version 2.0 introduces “Publisher Restrictions”, which, if exhausted by a publisher, could result in TC strings that are larger than the size limit for cookies. While this possibility is remote, it should be guarded against – a CMP should work with a publisher to help them accomplish their goals. CMPs may need to take this into consideration when deciding on the storage mechanism for those TC Strings.
There are 3 distincts TC String segments that are joined together on a “dot” character. They are:
The Core String is always required and comes first and includes all the details required for communicating basic vendor transparency and consent.
COw4XqLOw4XqLAAAAAENAXCAAAAAAAAAAAAAAAAAAAAA.IFukWSQgAIQwgI0QEByFAAAAeIAACAIgSAAQAIAgEQACEABAAAgAQFAEAIAAAGBAAgAAAAQAIFAAMCQAAgAAQiRAEQAAAAANAAIAAggAIYQFAAARmggBC3ZCYzU2yIA.QFukWSQgAIQwgI0QEByFAAAAeIAACAIgSAAQAIAgEQACEABAAAgAQFAEAIAAAGBAAgAAAAQAIFAAMCQAAgAAQiRAEQAAAAANAAIAAggAIYQFAAARmggBC3ZCYzU2yIA.YAAAAAAAAAAAAAAAAAA A TC String must contain a Core TC String and may optionally contain a Publisher TC segment :
CLcVDxRMWfGmWAVAHCENAXCkAKDAADnAABRgA5mdfCKZuYJez-NQm0TBMYA4oCAAGQYIAAAAAAEAIAEgAA.argAC0gAAAAAAAAAAAA The following fields are stored in big-endian format. Bit numberings are left-to-right.
| Field Name | Bits | Value(s) | Notes |
| Version | 6 bits | Version number of the encoding format | the value is 2 for this format. |
| Created | 36 bits | Epoch time format when TC String was last updated (must be updated any time a value is changed) | To create a timestamp in JavaScript: Math.round(Date.UTC(new Date().getUTCFullYear(), new Date().getUTCMonth(), new Date().getUTCDate())/100) . Also, the timestamp must be based in UTC time in order to get a consistent decisecond value across the time zones. |
(renamed from PurposesAllowed)
By default or if the user has exercised their “Right to Object” to a Purpose, the corresponding bit for that Purpose is set to 0 . From left to right, Purpose 1 maps to the 0th bit, and purpose 24 maps to the bit at index 23. Special Purposes are a different ID space and not included in this field.
Note: With TCF v2.2 support for legitimate interest for purpose 3 to 6 has been deprecated. Bits 2 to 5 are required to be set to 0 .
Each letter is encoded as 6 bits, a=0..z=25.
One bit for each Vendor:
1 Legitimate Interest established
0 Legitimate Interest not established or the user exercised their “Right to Object”
Set the bit corresponding to a given vendor to 1 if the CMP has established transparency for that vendor's legitimate interest disclosures for one or more Purposes (including Special Purposes).
If a user exercises their “Right To Object” to a vendor’s processing based on a legitimate interest, then that vendor’s bit must be set to 0 . For vendors that register for Special Purposes only (no other Purposes) and have been displayed by the CMP the value must be set to 1 . Note: Special Purposes are displayed for transparency only and do not enable user choice.
0 Purpose Flatly Not Allowed by Publisher (regardless of Vendor declarations)
1 Require Consent (if Vendor has declared the Purpose IDs legal basis as Legitimate Interest and flexible)
2 Require Legitimate Interest (if Vendor has declared the Purpose IDs legal basis as Consent and flexible)
3 UNDEFINED (not used)
Vendors must always respect a 0 (Not Allowed) regardless of whether or not they have not declared that Purpose to be “flexible”. Values 1 and 2 are in accordance with a vendor's declared flexibility. Eg. if a vendor has Purpose 2 declared as Legitimate Interest but also declares that Purpose as flexible and this field is set to 1 , they must then check for the “consent” signal in the VendorConsents section to make a determination on whether they have the legal basis for processing user personal data under that Purpose.
When a vendor's Purpose registration is not flexible they should interpret this value in the following ways:
If this value is 1 and vendor is registered under Legitimate Interest for that Purpose then the vendor should not process for that Purpose.
If this value is 1 and vendor is registered under Consent for that Purpose then the vendor can ignore the signal.
If this value is 2 and vendor is registered under Consent for that Purpose then the vendor should not process for that Purpose.
If this value is 2 and vendor is registered under Legitimate Interest for that Purpose then the vendor can ignore the signal.
If this value is 1 or 2 and the vendor is not registered for the Purpose then the vendor should not process for that Purpose.
Note: Purpose 1 is always required to be registered as a consent purpose and can not be flexible per Policies.
The DisclosedVendors is an optional TC String segment that records which vendors have been disclosed to a given user by a CMP. It may be used by a CMP while storing TC Strings, but must not be included in the TC String when returned by the CMP API.
1 DisclosedVendors
One bit for each vendor
1 Disclosed
0 Not Disclosed
Set the bit corresponding to a given vendor to 1 if the CMP has disclosed the vendor in the UI.
Publishers may need to establish transparency and consent for a set of personal data processing purposes for their own use. For example, a publisher that wants to set a frequency-capping first-party cookie should request user consent for Purpose 1 "Store and/or access information on a device" in jurisdictions where it is required.
The Publisher TC segment in the TC string represents the publisher's own transparency & consent signals and is separated from the general TC String segments. This segment supports the standard list of purposes defined by the TCF as well as Custom Purposes defined by the publisher if they so choose. Vendors should not rely on the Publisher TC segment unless they're in agreement with the publisher to do so.
3 PublisherTC
1 Consent
0 No Consent
The Purposes are numerically identified and published in the Global Vendor List. From left to right, Purpose 1 maps to the 0 th bit, purpose 24 maps to the bit at index 23.
By default or if the user has exercised their “Right to Object to a Purpose, the corresponding bit for that purpose is set to 0 . From left to right, Purpose 1 maps to the 0 th bit, purpose 24 maps to the bit at index 23.
If the publisher does not use any Custom Purposes, this field is set to 0 and the following two fields will be omitted.
1 Consent
0 No Consent
The Global Vendor List (GVL) is a technical document that CMPs download from a domain managed and published by IAB Europe. It lists all registered and approved Vendors, as well as standard Purposes, Special Purposes, Features, Special Features, Stacks, and categories of data collected in conjunction with the purposes. The information stored in the GVL is used for determining what legal disclosures must be made to the user.
The registration process is described here: https://iabeurope.eu/tcf
Additional information on Vendors can be downloaded from a domain managed and published by IAB Europe (see Additional Vendor Information List Specification)
The GVL is in JSON format and the current version at any given time can be retrieved using the following URL structure:
Previous versions of the Global Vendor List are available here:
Where ‘vendor-list-version’ corresponds to the ‘vendorListVersion’ property in the GVL, for example, the following URL would retrieve the GVL update published with version 138
Previous versions of the GVL may only be used in cases when the current version cannot be downloaded (such as when operating in-app while offline), or for change control management.
IMPORTANT NOTE: the original vendorlist.consensu.org domain has been decommissioned on January 31st 2021. The new domain for GVL resources is vendor-list.consensu.org.
For reference, the URL for version 1 of the TCF was:
Version 1 of the Global Vendor List and all version 1 archives will continue to be maintained until support officially ends in 2020. At that time, these files will be deprecated and only version 2 and newer of the Global Vendor List will be available.
Translations of the names and descriptions for Purposes, Special Purposes, Features, Special Features, and the categories of data used in conjunction with purposes to non-English languages are contained in a file where attributes containing English content (except vendor declaration information) are translated, and can be found here:
Where ‘language’ is a two letter lowercase ISO 639-1 language code. Supported languages are listed at the following URL:
As of the publication of this document, changes to the Global Vendor List are published weekly at 5:00 PM Central European Time on Thursdays. IAB Europe reserves the right to change this time and will notify CMP members of any changes.
CMPs must use the latest available version of the GVL whenever the interface is surfaced to the user to provide transparency or request consent. This condition applies to first-time and renewal interactions, as well as interactions that involve reviewing and updating settings.
In some cases, due to caching requirements and low connectivity environments, such as for mobile in-app experiences, it may not be possible to use the latest version of the GVL:
To determine whether the interface should be resurfaced to a user, the CMP must compare the latest version of the GVL with the archived version of the GVL identified in the TC String (assuming they are different). The CMP is not required to resurface the interface to the user if the versions are different. The timing and reasons for resurfacing the interface to users is at the discretion of the CMP and the publisher.
Strict restrictions on accessing and caching the GVL apply and are detailed below.
Vendors must use the version of the GVL encoded in the TC String received to:
Strict restrictions on accessing and caching the GVL apply and are detailed below.
In TCF v1 it was possible for client-side CMP applications to load the GVL directly via CORS. Given the scale of the TCF and the high volume of requests for the Global Vendor List, this is no longer possible from TCF v2.0 onward. All requests for the GVL must now be server-side.
Current and previous GVL resources, as well as purpose translations, are configured with cache-control headers. Server-side applications must cache these resources in the same way that a browser would - the file must be requested and cached using the specified max-age value in the header. Once the cache expires, the resource can be requested again. Resources must not be cached for a period other than max-age .
Previous versions of the GVL must be cached for at least the period specified by the cache-control headers and may be cached indefinitely as they are static resources.
Client-side CMP applications must not load GVL resources directly from vendor-list.consensu.org - instead they must be loaded and hosted by a CMP’s server-side application and then passed to the client-side CMP application.
As stated above, CMP server-side applications must cache these resources in the same way that a browser would. For example, if the max-age value in the header is one week, the server-side application must do the following:
Important: The volume of usage will be monitored carefully by the managing organisation and any CMP not adhering to this request limit will be blocked from accessing the GVL.
To prevent client-side applications from repeatedly downloading files, CMPs should set cache-control headers on HTTP responses sent to client-side requests for their self-hosted GVL resources. This will ensure that browsers automatically cache the resources, circumventing the need to repeatedly request files over HTTP.
Vendor requests for GVL resources must be loaded and cached by the server-side application.
As stated above, vendor server-side applications must cache these resources in the same way that a browser would. For example, if the max-age value in the header is one week, the server-side application must do the following:
Important: The volume of usage will be monitored carefully by the managing organisation and any vendor not adhering to this request limit will be blocked from accessing the GVL.
In order to control the bandwidth used by requests for the GVL file, vendors and CMPs must request a compressed version of the GVL. This can be done by sending Accept-Encoding headers on the GET request for the file.
Example:
Accept-Encoding: gzip, deflate, br A browser will add this header automatically and, therefore, nothing needs to be done for an in-browser request. Server-side requests are another matter because server software may not decompress the response automatically. Make sure your server requests send the options your service is capable of decoding in your Accept-Encoding header.
When a change occurs in the TCF Policies, the MO may indicate that changes are of such a nature as to require re-establishing Legal Bases. These policy changes happen infrequently, but when they do, a CMP is required to discard the user’s current TC String and resurface the user interface to provide new disclosures, capture new consent, and encode a new TC String without migrating any old values over from the old one - under the timeline provided by the MO for the transition.
To determine if TCF Policies have changed, CMPs shall compare the TcfPolicyVersion encoded in a TC String with the TcfPolicyVersion property in the latest Global Vendor List published by the Managing Organisation.
Here is an annotated example of the GVL’s JSON format and content. Some attributes are described in the tables following the example:
"gvlSpecificationVersion": 3, "vendorListVersion": 1, // incremented with each published file change "tcfPolicyVersion": 4, // The TCF MO will increment this value whenever a GVL change (such as adding a new Purpose or Feature or a change in Purpose wording) legally invalidates existing TC Strings and requires CMPs to re-establish transparency and consent from users. TCF Policy changes should be relatively infrequent and only occur when necessary to support changes in global mandate. If the policy version number in the latest GVL is different from the value in your TC String, then you need to re-establish transparency and consent for that user. A version 1 format TC String is considered to have a version value of 1. "lastUpdated": "2023-05-26T16:00:00Z", "purposes": /** * Information published for each Purpose * * "id": number, REQUIRED * "name": string, REQUIRED * "description": string, REQUIRED * "illustrations": string array, REQUIRED * "consentable": boolean, OPTIONAL, default=true false means CMPs should never afford users the means to provide an opt-in consent choice * "rightToObject": boolean, OPTIONAL, default=true false means CMPs should never afford users the means to exercise a right to object */ "1": "id": 1, "name": "Storage and access of information", "description": ". ", "illustrations": [ ] >, // . more purposes from to (up to no higher than >"10": "id": 10, "name": "Develop and improve product", "description": ". ", "illustrations": [ ], "consentable": false, "rightToObject": false > >, "specialPurposes" : "1": "id": 1, "name": "Security, Fraud Prevention, Debugging", "description": ". ", "illustrations": [ ], "consentable": false, "rightToObject": false >, "2": "id": 2, "name": "Technical ad and content delivery", "description": ". ", "illustrations": [ ], "consentable": false, "rightToObject": false > >, "features" : "1": "id": 1, "name": "Matching Data to Offline Sources", "description": "Combining data from offline sources that were initially collected in other contexts", "illustrations": [ ] > // . more features from up to no higher than >, /** * Special features differ from simple features in that CMPs MUST provide * users with a means to signal an opt-in choice as to whether vendors * may employ the feature when performing any purpose processing. * See Policies for specifics. */ "specialFeatures" : "1": "id": 1, "name": "Precise Geolocation", "description": ". ", "illustrations": [ ] >, "2": "id": 2, "name": "Active Fingerprinting", "description": ". ", "illustrations": [ ] > // . more special features from up to no higher than // >, "stacks": "1": "id": 1, "purposes" : [], "specialFeatures" : [1,2], "name" : "Precise geolocation data, and identification through device scanning", "description" : "Precise geolocation and information about device characteristics can be used." > // . more Stacks. // >, "dataCategories": "1": "id": 1, "name" : "IP addresses", "description" : ". " > // . more dataCategories. // >, "vendors": /** * Information published for each vendor * * "id": numeric, REQUIRED * * "name": string, REQUIRED * * "purposes": conditionally OPTIONAL (see "Constraints") array of positive * integers. List of Purpose ids declared as performed on the legal basis of * consent * * "legIntPurposes" conditionally OPTIONAL (see "Constraints") array of * positive integers. List of Purpose ids declared as performed on the legal * basis of legitimate interest * * "flexiblePurposes": OPTIONAL array of positive integers. Array may be * empty. List of purpose ids where the vendor is flexible regarding the * legal basis; they will perform the processing based on consent or a * legitimate interest. The 'default' is determined by which of the other two * mutually-exclusive purpose fields is used to declare the purpose for the * vendor * * Constraints: * Either purposes OR legIntPurposes can be missing/empty, but not both * unless the vendor declared one of more specical purpose but no purposes. * * A Purpose id must not be present in both purposes and legIntPurposes. * * A Purpose id listed in flexiblePurposes must have been declared in one * of purposes or legIntPurposes. * * Purpose id values included in the three purpose fields must be in the * range from 1 to N, where N is the highest purpose id published in this * GVL file. * * "specialPurposes": array of positive integers, OPTIONAL. Array may be * empty. List of Special Purposes declared as performed on the legal basis * of a legitimate interest * * "features": array of positive integers, OPTIONAL. Array may be empty. List * of Features the Vendor may utilize when performing some declared Purposes * processing. * * "specialFeatures": array of positive integers, OPTIONAL. Array may be * empty. List of Special Features the Vendor may utilize when performing * some declared Purposes processing. * * "dataDeclaration": An array of positive integers that represent * the data categories declared by the vendor. * * "dataRetention": an object that contains the data retention in days for the * purpose and specialPurpose declared by the vendor. A stdRetention is computed * and added if there is an absolute total of equal retention periods found. * * "urls": an array of url objects representing language, policy url and * legitimate interest url. At least one entry is REQUIRED. Up to 40 languages * can be specified. * * "deletedDate": date string ("2019-05-28T00:00:00Z") OPTIONAL, If present, * vendor is considered deleted after this date/time and MUST NOT be * established to users. * * "overflow": object specifying the vendor's http GET request length limit * OPTIONAL. Has the following members & values * * "overflow": * "httpGetLimit": 32 // 32 or 128 are supported options * > * If a vendor entry does not include this attribute then the vendor has no * overflow options and none can be inferred. * * Attributes for disclosures related to the Planet49 ruling. * See the descriptions immediately after this example. * * "usesCookies": boolean, REQUIRED * "cookieMaxAgeSeconds" : numeric, REQUIRED * "cookieRefresh" : boolean, REQUIRED * "usesNonCookieAccess" : boolean, REQUIRED * "deviceStorageDisclosureUrl" : url string, REQUIRED * */ "1": "id": 1, "name": "Vendor Name", "purposes": [1, 2, 3, 9], "specialPurposes": [1], "legIntPurposes": [7], "flexiblePurposes": [1, 2], "features": [1, 2], "specialFeatures": [1, 2], "dataRetention": "stdRetention": 30 "purposes": "9": 180 >, "specialPurposes": > >, "dataDeclaration" : [ 1, 2, 4, 6 ], "urls": [ "langId": "en", "privacy": "https://vendorname.com/gdpr.html", "legIntClaim": "https://vendorname.com/gdpr.html#li" >, "langId": "fr", "privacy": "https://vendorname.com/fr/gdpr.html", "legIntClaim": "https://vendorname.com/fr/gdpr.html#li" > ], "deletedDate": "2019-02-28T00:00:00Z", "overflow": "httpGetLimit": 32 >, "usesCookies": true, "cookieMaxAgeSeconds": 31536000, "cookieRefresh": false, "usesNonCookieAccess": true, "deviceStorageDisclosureUrl": "https://vendorname.com/path/to/file.json" > // . more vendors > >
The fields below provide Vendors with a method to disclose the length of time any vendor-specific information may be stored on a device and other summary information about device storage. Vendors also provide granular storage and access disclosures via a JSON file. CMPs display this information to consumers. This form of transparency took on urgency after a ruling by the Court of Justice of the European Union in Case C-673/17 Planet49.
In its Planet49 judgment (available here), the Court of Justice of the European Union (CJEU) ruled that the requirements for informed consent under Article 5(3) of the ePrivacy Directive include the disclosure of “the duration of the operation of cookies and whether or not third parties may have access to those cookies” (para. 81). 1 The CJEU clarified that the information provided must enable the user to determine the consequences of any consent and be sufficiently detailed so as to enable the user to understand the functioning of the cookies employed. This includes the requirement to provide information about the duration of the cookies and whether or not third parties may have access to those cookies.
This true or false field indicates whether the vendor uses cookie storage (session or otherwise).
| Field | Type | Description |
| usesCookies | Boolean | Indicates whether the vendor uses cookie storage (session or otherwise). True indicates cookie storage is used. False cookie storage is not used. |
The number of seconds representing the longest potential duration for cookie storage on a device. If a Vendor uses multiple cookies with differing durations, cookieMaxAgeSeconds represents the cookie with the longest duration. Note: cookies are the only method of storage or device access that permit a predictable duration to be set.
| Field | Type | Description |
| cookieMaxAgeSeconds | integer | The number, in seconds, of the longest potential duration for storage on a device, as set when using the cookie method of storage. A negative number or a 0 indicates session storage similar to the Set-Cookie spec. A null value is provided when usesCookies=false . Note: this only includes what is declared when the storage is initially set and does not consider duration extensions should storage be refreshed. |
This true or false field indicates whether any cookies in scope for cookieMaxAgeSeconds are refreshed after being initially set. The following is an example of a cookie "refresh" scenario. On Day 0 a user visits a web page which loads Vendor A who seeks Purpose 1 consent. She consents to Purpose 1 which includes Vendor A's 90 day max age cookie disclosure. This cookie is set to expire 90 days from now on Day 90 using Set-Cookie: Max-Age=7776000 . On Day 5 the same user again visits the same web page loading Vendor A. The web page's CMP previously recorded her data processing choices and does not surface a new consent request. Vendor A is considered to "refresh" the cookie if it resets the countdown to 90 days from day 5, which would now be 96 days after the user made her choice when the webpage's CMP displayed a transparency and control experience to her.
| Field | Type | Description |
| cookieRefresh | boolean | True indicates the vendor may refresh cookie(s). False indicates the vendor does not refresh any time the browser reloads. |
This true or false field indicates whether the vendor uses other, non-cookie methods of storage or accessing information already stored on a user’s device (see footnote 1). Examples of non-cookie storage and access may be localStorage, indexDB, mobile ad IDs, etc.
| Field | Type | Description |
| usesNonCookieAccess | boolean | Indicates the vendor’s use of non-cookie storage and access to information already stored on a user’s device. True indicates non-cookie access is used. False indicates non-cookie storage and access to information already stored on a user's device is not used. |
| Field | Type | Description |
| deviceStorageDisclosureUrl | string | This required field is a secure URL to a vendor-hosted resource that adheres to the structure, content and serving described by the Vendor Device Storage & Operational Disclosures specification. |
The Global CMP List (GCL) is a JSON format document that lists all CMPs registered with the Transparency and Consent Framework (TCF). There are separate files for each version of the framework. Currently, we only support TCF v2. These files are used by vendors to determine which CMPs are compliant and active within the framework, in order to ascertain whether a given CMP ID found in a consent string or TC String is valid.
IMPORTANT NOTE: all CMPs that have registered with the TCF are listed in these files. CMPs that are no longer active for whatever reason, have the deletedDate property set. Consent strings or TC Strings for CMPs with a deletedDate set must be considered invalid after that date/time and must be discarded immediately and not passed downstream.
The GCL is in JSON format and the current version at any given time can be retrieved using the following URL:
As of the publication of this document, changes to the Global CMP List are published weekly at 5:00 PM Central European Time on Thursdays. IAB Europe reserves the right to change this time and will notify members of any changes.
Strict restrictions on caching the GCL apply.
All requests for the Global CMP List must honour the cache-control headers and must not cache the resource with different settings.
Note: There may be a delay of up to the maximum cache interval in retrieving the latest version of the Global CMP List.
As requests for a GCL file will not be in a browser context, GCL files must be cached explicitly server-side according to the cache-control headers.
Application logic must only request one version of the GCL during the cache period specified in the cache-control header. For example, if the caching period is one week, only one request for the current GCL file must be received per week.
Note: The volume of usage will be monitored carefully by the managing organisation (MO) and any organisations not adhering to this request limit will be blocked from accessing the GCL.
A compressed version of the GCL must be requested. This can be done by sending Accept-Encoding headers on the GET request for the file:
Here is an example of the GCL’s JSON format:
< "lastUpdated": "2019-10-31T00:00:00Z", "cmps": < /** * Information published for each CMP * * "id": numeric, REQUIRED * "name": string, REQUIRED * "isCommercial": boolean, REQUIRED * "environments": array of enum, REQUIRED. Indicates the environments where * the CMP operates. ‘web’, ‘native app (mobile)’, ‘native app (CTV)’, * ‘other’. * "deletedDate": date string ("2019-05-28T00:00:00Z") OPTIONAL * If present, CMP is considered deleted after this date/time and * consent string or TC String must be discarded immediately. */ "2":< "id": 2, "name": "Chandago", "isCommercial": true, "environments": ["web","other"] >, // . more CMPs "136": < "id": 136, "name": "M6 Web", "isCommercial": false, "environments: ["web","native app (mobile)"], "deletedDate": "2019-08-06T00:00:00Z" >// . more CMPs > > 