IAB Transparency & Consent Framework (TCF): The Complete Guide

The digital advertising ecosystem involves hundreds of companies processing personal data in fractions of a second. When a webpage loads, data about the visitor can flow through dozens of ad tech vendors — demand-side platforms, supply-side platforms, data management platforms, analytics providers, and more. The IAB Transparency & Consent Framework (TCF) exists to bring order to this complexity by providing a standardized way to collect, encode, and distribute user consent signals across the entire programmatic advertising chain.

Without a common framework, every publisher would need to negotiate consent mechanisms with every vendor individually. The TCF solves this by defining a shared language for consent: a structured data format (the TC String), a JavaScript API (__tcfapi()), and a governance model that holds participants accountable. Since its introduction in 2018, the TCF has become the dominant consent standard in European digital advertising, with adoption by thousands of publishers and hundreds of vendors.

Why the TCF Exists

The General Data Protection Regulation (GDPR) requires that personal data processing has a valid legal basis. For most ad tech activities, this means either explicit user consent or a legitimate interest assessment. But the GDPR does not specify how consent should be technically communicated between a publisher's website and the many third-party vendors that participate in programmatic advertising.

This gap created significant practical problems. Publishers had no way to efficiently tell their ad tech partners which purposes a user had consented to. Vendors had no standardized way to check whether they had permission to process data. The result was fragmentation: incompatible consent tools, inconsistent user experiences, and widespread uncertainty about compliance.

The IAB Europe developed the TCF to address these issues. It provides:

• A standardized taxonomy of data processing purposes that vendors can register against
• A compact, machine-readable consent string that travels with ad requests
• A JavaScript API that any script on the page can query to check consent status
• A governance framework with registration, auditing, and enforcement mechanisms
• A Global Vendor List (GVL) that serves as a central registry of participating vendors and their declared purposes

TCF 2.2 vs TCF 2.3 — What Changed

The TCF has evolved through several versions. TCF v1.1 was the original release, replaced by TCF v2.0 in August 2019 with significant architectural changes. TCF v2.2 followed in May 2023, and TCF v2.3 is the current version, introducing further refinements. Understanding the differences between 2.2 and 2.3 is important for anyone implementing or auditing consent mechanisms.

Policy Version 5. TCF v2.3 introduces Policy Version 5 in the TC String. This signals to vendors that the string was generated under the latest set of policies and technical specifications. Vendors can use this field to determine which rules apply when interpreting the consent data.

DisclosedVendors segment becomes mandatory. In TCF v2.2, the DisclosedVendors segment of the TC String was optional. In v2.3, CMPs are required to include this segment, which lists all vendors that were actually presented to the user in the consent interface. This closes a transparency gap: vendors can now verify not just whether consent was given, but whether the user was actually informed about their participation.

Legitimate interest restrictions. TCF v2.3 tightens the rules around legitimate interest as a legal basis. Several purposes that previously allowed legitimate interest now require explicit consent. This reflects the evolving regulatory guidance from European data protection authorities, particularly the Belgian DPA's decision that found aspects of the TCF's legitimate interest implementation problematic.

Additional technical refinements. TCF v2.3 also includes updates to the CMP API behavior, clarification of event handling, and stricter requirements for how CMPs must surface vendor information to users. The getTCData command response includes additional fields for more granular consent checking.

Key Concepts

The TCF is built on several interlocking concepts. Understanding these is essential for anyone working with consent in the ad tech ecosystem.

CMP (Consent Management Platform). A CMP is the software that presents the consent interface to the user — the cookie banner or consent dialog. CMPs must be registered with IAB Europe and assigned a unique CMP ID. They are responsible for generating the TC String based on user choices and making it available via the __tcfapi() JavaScript API. Examples of CMPs include Cookiebot, OneTrust, Quantcast Choice, and Didomi.

GVL (Global Vendor List). The GVL is a machine-readable JSON file maintained by IAB Europe that lists every registered vendor along with the purposes, special purposes, features, and special features they have declared. CMPs use the GVL to populate their consent interfaces. The GVL is versioned and updated regularly as vendors join, leave, or change their declarations. It is available at https://vendor-list.consensu.org/v3/vendor-list.json.

Purposes (1–11). The TCF defines a fixed set of purposes that describe why personal data is processed:

• Purpose 1: Store and/or access information on a device
• Purpose 2: Select basic ads
• Purpose 3: Create a personalised ads profile
• Purpose 4: Select personalised ads
• Purpose 5: Create a personalised content profile
• Purpose 6: Select personalised content
• Purpose 7: Measure ad performance
• Purpose 8: Measure content performance
• Purpose 9: Apply market research to generate audience insights
• Purpose 10: Develop and improve products
• Purpose 11: Use limited data to select content

Each purpose has a defined legal basis: some allow consent only, others allow either consent or legitimate interest. Under TCF v2.3, the purposes that can rely on legitimate interest have been further restricted.

Special Purposes. Special purposes are processing activities that vendors may perform without requiring consent or legitimate interest approval from the user, because they are considered essential. There are two special purposes: ensuring security, preventing fraud, and debugging (Special Purpose 1), and technically delivering ads or content (Special Purpose 2). Users must be informed about these, but cannot opt out.

Features and Special Features. Features describe technical methods of data processing (such as matching and combining data from different sources, or linking different devices). They do not have their own legal basis — they rely on the legal basis of the purposes they support. Special features are similar but require explicit opt-in consent. There are two special features: using precise geolocation data, and actively scanning device characteristics for identification.

Stacks. Stacks are predefined groupings of purposes and special features that CMPs can present together in their user interface to simplify the consent experience. For example, a stack might group "personalised ads" and "ad measurement" together. When a CMP uses stacks, it must still allow users to make choices at the individual purpose level.

The TC String

The TC String (Transparency and Consent String) is the core data artifact of the TCF. It is a compact, base64url-encoded binary string that encodes all of a user's consent and objection choices, along with metadata about when and how those choices were collected.

A TC String looks something like this:

CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA.YAAAAAAAAAAA

The string is divided into up to three segments, separated by periods (.):

1. Core Segment (required). This contains the essential consent data:

• Version number (6 bits)
• Date created and last updated (36 bits each, deciseconds since epoch)
• CMP ID and CMP version (12 bits each)
• Consent screen number (6 bits)
• Consent language (12 bits, ISO 639-1)
• Vendor list version (12 bits)
• TCF policy version (6 bits — value 5 for TCF v2.3)
• Whether the CMP uses a service-specific scope (1 bit)
• Purpose consents (24 bits, one per purpose)
• Purpose legitimate interests (24 bits)
• Publisher restrictions (variable length)
• Vendor consents (variable length, using range or bitfield encoding)
• Vendor legitimate interests (variable length)

2. DisclosedVendors Segment (mandatory in TCF v2.3). This lists all vendor IDs that the CMP disclosed to the user in the consent interface. It uses the same bitfield or range encoding as the vendor fields in the core segment. This segment allows vendors to verify that users were actually informed about their participation before consent was granted.

3. PublisherTC Segment (optional). This contains publisher-specific purpose consents and legitimate interest choices, as well as custom purpose declarations. It allows publishers to define and collect consent for their own data processing purposes beyond the standard TCF purposes.

The binary data is encoded using base64url (RFC 4648), which uses the characters A-Z, a-z, 0-9, -, and _ (replacing the + and / of standard base64). No padding characters are used.

The __tcfapi() JavaScript API

The TCF defines a JavaScript API that CMPs must implement, accessible via the global function __tcfapi(). Any script on the page — ad tags, analytics libraries, tracking pixels — can call this function to check the current consent status.

The API signature is:

__tcfapi(command, version, callback, parameter)

The supported commands are:

ping — Returns immediately with information about the CMP's loading status. This is the only command that works before the CMP has fully loaded. The callback receives a PingReturn object containing the CMP ID, CMP version, whether the GDPR applies, and whether the CMP has loaded and displayed the consent UI.

__tcfapi('ping', 2, function(pingReturn) {
    console.log('CMP loaded:', pingReturn.cmpLoaded);
    console.log('GDPR applies:', pingReturn.gdprApplies);
    console.log('CMP ID:', pingReturn.cmpId);
});

getTCData — Returns the full consent data. The callback receives a TCData object containing purpose consents, vendor consents, legitimate interest statuses, and the raw TC String. You can optionally pass an array of vendor IDs to filter the response.

__tcfapi('getTCData', 2, function(tcData, success) {
    if (success) {
        console.log('TC String:', tcData.tcString);
        console.log('Purpose 1 consent:', tcData.purpose.consents[1]);
        console.log('Vendor 755 consent:', tcData.vendor.consents[755]);
    }
}, [755, 132]);

addEventListener — Registers a callback that is invoked whenever the consent status changes. This is the recommended approach for scripts that need to react to consent changes in real time, such as when a user updates their preferences. The callback receives a TCData object with an additional listenerId property and an eventStatus field indicating whether the CMP UI is currently shown (cmpuishown), the user has made a choice (useractioncomplete), or consent was loaded from storage (tcloaded).

__tcfapi('addEventListener', 2, function(tcData, success) {
    if (success && tcData.eventStatus === 'useractioncomplete') {
        // User has made their consent choices
        if (tcData.purpose.consents[1]) {
            // Purpose 1 (storage access) granted
            initializeTracking();
        }
    }
});

removeEventListener — Removes a previously registered event listener by its listenerId.

__tcfapi('removeEventListener', 2, function(success) {
    console.log('Listener removed:', success);
}, listenerId);

Cross-Frame Communication

In programmatic advertising, many vendors operate within iframes — they do not have direct access to the parent page's JavaScript context. The TCF solves this with a cross-frame communication protocol based on postMessage.

The __tcfapiLocator iframe. When a CMP loads, it creates a hidden iframe named __tcfapiLocator and inserts it into the page. Vendor scripts running inside iframes use this locator to find the CMP. They walk up the frame hierarchy, checking each ancestor for the presence of __tcfapiLocator. Once found, they know which frame to send postMessage calls to.

The postMessage protocol. Vendor scripts in iframes communicate with the CMP by sending structured messages to the parent frame. A request message has this format:

window.parent.postMessage({
    __tcfapiCall: {
        command: 'getTCData',
        version: 2,
        callId: 'unique-id-123',
        parameter: [vendorId]
    }
}, '*');

The CMP responds with a message in this format:

{
    __tcfapiReturn: {
        returnValue: { /* TCData object */ },
        success: true,
        callId: 'unique-id-123'
    }
}

The callId is used to match responses with their corresponding requests, since postMessage is asynchronous. Vendor scripts typically include a stub that abstracts this protocol, presenting the same __tcfapi() interface regardless of whether the script runs in the top frame or an iframe.

The euconsent-v2 Cookie

The TC String is persisted in a first-party cookie named euconsent-v2. This cookie is set by the CMP on the publisher's domain so that consent choices survive page navigations and return visits. The cookie's value is the raw TC String.

Key characteristics of this cookie:

• It is a first-party cookie, set on the publisher's domain
• Its value is the complete TC String (all segments)
• The CMP is responsible for setting, updating, and managing its expiration
• Third-party scripts should read consent via the __tcfapi() API rather than parsing the cookie directly, because the API provides a structured interface and handles edge cases like CMP-not-yet-loaded states
• Some CMPs additionally store consent in localStorage as a fallback

The name euconsent-v2 reflects that this is the second version of the consent cookie format (the original TCF v1.1 used euconsent). Despite the name, the same cookie is used for TCF v2.0, v2.2, and v2.3 — the TC String's internal version and policy version fields indicate which specification applies.

CMP Registration with IAB

To participate in the TCF, a CMP must register with IAB Europe through the registration portal at register.consensu.org. Registration involves several requirements:

• The CMP operator must agree to the TCF Policies and comply with all technical specifications
• Each registered CMP receives a unique numeric CMP ID, which is embedded in every TC String it generates
• CMPs must pass a validation process demonstrating that their implementation correctly generates TC Strings and implements the __tcfapi() API
• CMPs are subject to ongoing compliance monitoring and can have their registration revoked for violations
• Annual registration fees apply, with pricing tiers based on the CMP's scale

The CMP ID serves as an accountability mechanism. Any TC String can be traced back to the CMP that generated it, and that CMP is responsible for the accuracy of the consent it encodes. If a regulatory investigation finds that consent was not properly collected, the CMP ID identifies who is responsible.

How Vendors Read Consent

For a vendor to determine whether it has permission to process data for a specific purpose, it must check two things in the TC String: purpose consent and vendor consent. Both must be present.

The logic works as follows:

• Step 1: Check whether the user has granted consent for the relevant purpose (e.g., Purpose 1 for storage access, Purpose 3 for personalised ads profiling)
• Step 2: Check whether the user has granted consent for the specific vendor ID
• Step 3: If using legitimate interest as the legal basis, check the legitimate interest fields instead and verify that the publisher has not applied a restriction that overrides the vendor's legitimate interest claim
• Step 4: Verify that the vendor appears in the DisclosedVendors segment (mandatory in TCF v2.3), confirming that the user was actually informed about the vendor

In code, a simplified consent check looks like this:

__tcfapi('getTCData', 2, function(tcData, success) {
    if (!success) return;

    var vendorId = 755; // Example vendor ID
    var hasVendorConsent = tcData.vendor.consents[vendorId];
    var hasPurpose1 = tcData.purpose.consents[1]; // Storage access
    var hasPurpose3 = tcData.purpose.consents[3]; // Ad profiling

    if (hasVendorConsent && hasPurpose1) {
        // Allowed to set cookies / access storage
    }
    if (hasVendorConsent && hasPurpose3) {
        // Allowed to build ad profile
    }
}, [755]);

Vendors should never assume consent. If gdprApplies is true (checked via the ping command), the vendor must have positive consent signals before processing data.

Google's Additional Consent Mode

The TCF's Global Vendor List does not include every ad tech vendor. Google operates its own ad network with many technology providers that are not registered in the GVL. To handle consent for these non-IAB vendors, Google developed the Additional Consent Mode specification.

This works through an additional consent string, sometimes called the addtl_consent string or AC String. It is stored alongside the TC String and follows a separate format:

2~1.35.41.101~

The format consists of:

• A version number (currently 2)
• A tilde separator (~)
• A period-separated list of Google Ad Technology Provider (ATP) IDs that the user has consented to
• A trailing tilde

CMPs that support Google's Additional Consent Mode display Google's ATP list alongside the standard GVL vendors in their consent interface. The resulting AC String is typically stored in a cookie or made available through the CMP's API. Google's ad serving systems check both the TC String (for IAB-registered purposes and vendors) and the AC String (for non-IAB ATPs) when determining whether to serve personalised ads.

It is worth noting that the Additional Consent Mode is a Google-specific extension, not part of the IAB TCF specification itself. However, given Google's dominance in the ad tech ecosystem, most major CMPs support it.

TCF and GDPR: How They Relate

The TCF is not a legal framework — it is a technical implementation that facilitates compliance with the GDPR (and the ePrivacy Directive). Understanding the relationship between the two is important for publishers and vendors alike.

Consent as a legal basis. Under GDPR Article 6(1)(a), consent must be freely given, specific, informed, and unambiguous. The TCF implements this by requiring CMPs to present clear, purpose-level choices to users and to encode those choices in a verifiable format. The TC String provides an auditable record of what the user consented to, when, and through which CMP.

Legitimate interest as a legal basis. Under GDPR Article 6(1)(f), data processing can be based on a controller's or third party's legitimate interest, provided it does not override the data subject's rights. The TCF allows vendors to declare legitimate interest for certain purposes, but TCF v2.3 has significantly restricted which purposes can use this basis. Publishers can further restrict legitimate interest claims through publisher restrictions in the TC String.

The ePrivacy Directive. Purpose 1 (store and/or access information on a device) relates specifically to the ePrivacy Directive (often called the "cookie law"), which requires consent for placing cookies or accessing device storage. This purpose only allows consent as a legal basis — legitimate interest is never valid for storage access.

Regulatory scrutiny. The TCF has faced regulatory challenges. In February 2022, the Belgian Data Protection Authority (APD) ruled that IAB Europe was a data controller for the TC String itself and found several GDPR violations in the TCF's operation. This led to changes in TCF governance and contributed to the stricter requirements in TCF v2.2 and v2.3. The case highlighted that using the TCF does not automatically guarantee GDPR compliance — the quality of the CMP's implementation and the accuracy of consent collection remain critical.

Right to withdraw consent. The GDPR requires that withdrawing consent must be as easy as giving it. CMPs must provide an accessible way for users to revisit and change their consent choices. The TCF supports this through the addEventListener mechanism, which notifies vendors when consent status changes, and through the ability to generate updated TC Strings when users modify their preferences.

Implementation Considerations for Website Owners

If you are a publisher or website owner implementing the TCF, several practical considerations affect both compliance and user experience:

Choosing a CMP. Select a CMP that is registered with IAB Europe and supports TCF v2.3. Consider the CMP's customization options, language support, accessibility of its consent interface, loading performance, and cost. Major options include Cookiebot, OneTrust, Quantcast Choice, Didomi, and Usercentrics. Verify that the CMP supports Google's Additional Consent Mode if you use Google ad products.

Configuring vendor lists. Only include vendors that you actually work with. Presenting users with hundreds of vendors they have never heard of damages trust and increases the likelihood of blanket rejection. Review your vendor list regularly and remove vendors you no longer use.

Consent before processing. Ensure that no tracking scripts, cookies, or data collection occurs before the user has made a consent choice. This means implementing a tag management strategy that gates script loading on consent signals. Many CMPs integrate with tag managers (such as Google Tag Manager) to automate this.

Performance impact. The CMP script and the consent interaction add latency to page loads. Choose a CMP with a lightweight JavaScript footprint and consider async loading patterns. Be aware that gating ad scripts on consent will affect ad revenue — ads cannot load until the user interacts with the consent banner.

Cross-domain consent. If you operate multiple domains, consider whether consent should be shared across them or collected independently. Service-specific scope (indicated by the isServiceSpecific flag in the TC String) means consent applies only to the current site. Cross-domain consent sharing requires additional infrastructure and has stricter privacy implications.

Consent record keeping. Maintain records of consent that include what was presented to the user, when consent was given, and what version of the vendor list and purposes were in effect. Many CMPs provide dashboards for consent analytics. These records are essential for demonstrating compliance in the event of a regulatory inquiry.

Common Pitfalls and Compliance Issues

TCF implementation is frequently done incorrectly. These are the most common issues that regulators and auditors flag:

• Pre-ticked boxes: Some CMPs are configured with purposes or vendors pre-selected, which violates the GDPR's requirement that consent be an affirmative act. All purpose and vendor toggles must default to "off."
• Dark patterns: Making the "Accept All" button visually prominent while hiding or downplaying the "Reject All" or "Manage Preferences" options. Regulators increasingly require that rejecting consent be as easy as accepting it.
• Cookie walls: Blocking access to content unless the user consents to data processing. This is generally considered non-compliant in the EU, as consent is not freely given if access to the service is conditional on it.
• Scripts firing before consent: Loading tracking scripts, ad tags, or analytics before the user has interacted with the CMP. This is one of the most common and most serious violations.
• Stale vendor lists: Failing to update the CMP configuration when the GVL is updated. Vendors may change their declared purposes, new vendors may be added, or vendors may be removed from the list.
• Ignoring legitimate interest restrictions: Relying on legitimate interest for purposes where TCF v2.3 now requires consent. This is especially common for vendors that have not updated their implementations after the v2.2 to v2.3 transition.
• Missing euconsent-v2 cookie: If the consent cookie is not being set or is being cleared by other scripts, consent choices are lost between page loads, leading to the CMP re-appearing on every visit.
• Inadequate vendor disclosure: Not listing all vendors that actually process data on the site. If a vendor processes data but is not included in the consent interface, there is no valid legal basis for that processing.
• Inaccessible consent interfaces: Many CMPs produce consent dialogs that are not keyboard-navigable, lack proper ARIA attributes, or are difficult to use with screen readers. This creates both an accessibility barrier and a potential compliance issue, as users with disabilities cannot meaningfully exercise their consent rights.

How Passiro Detects TCF Compliance Issues

Passiro's automated scanner checks for TCF-related issues as part of its accessibility and compliance analysis. When scanning a website, Passiro evaluates whether the consent management implementation follows best practices and identifies potential problems.

The scanner detects the presence of the __tcfapi() API and the euconsent-v2 cookie, checks whether consent dialogs are accessible (keyboard navigation, focus management, screen reader compatibility), and flags common issues like scripts loading before consent is established. This gives website owners a clear picture of their TCF implementation status alongside their accessibility compliance score.

If you want to check how your website handles consent and accessibility, you can run a free scan and see the results in minutes.