If your website relies on programmatic advertising: whether through Google AdSense, Google Ad Manager, header bidding or real-time bidding (RTB) exchanges: you almost certainly need to comply with the IAB Transparency and Consent Framework (TCF). Developed by IAB Europe in direct response to GDPR, TCF has become the de facto industry standard for collecting, encoding and transmitting user consent across the digital advertising supply chain. In this comprehensive guide we explain what TCF is, how it works under the hood, what changed between versions 2.0 and 2.2, why European regulators have scrutinised the framework, and how you can implement it on your website without getting lost in the technical details.

The problem TCF was designed to solve

Before GDPR came into force on 25 May 2018, the digital advertising ecosystem operated with relatively few constraints on data collection. Advertisers, ad exchanges, demand-side platforms (DSPs) and supply-side platforms (SSPs) freely shared user data: browser fingerprints, cookie IDs, browsing histories: to serve targeted adverts. GDPR changed this by requiring a lawful basis (most commonly consent) before personal data could be processed.

The challenge was immediately apparent: a single page load on an ad-supported website can involve dozens, sometimes hundreds, of different companies processing user data in milliseconds. How could a publisher collect meaningful consent for each of these vendors, and how could that consent signal travel through the entire programmatic chain in the fraction of a second it takes to run an auction?

IAB Europe's answer was the Transparency and Consent Framework: a technical specification that standardises the way consent is collected by publishers, encoded into a machine-readable string and passed to every participant in the advertising supply chain.

What is IAB TCF?

The IAB Transparency and Consent Framework (TCF) is an open, cross-industry protocol that defines three things:

  • How consent should be collected: through a registered Consent Management Platform (CMP) that presents users with standardised information about data processing purposes and vendors.
  • What processing purposes exist: TCF defines a fixed list of purposes (such as "Store and/or access information on a device", "Select basic ads", "Measure ad performance") and special features, ensuring consistency across the industry.
  • How consent signals should be transmitted: through a standardised encoded string (the TC String) that every participant in the ad tech chain can read and act upon.

TCF is maintained by IAB Europe and governed by a set of policies that CMPs, publishers and vendors must follow if they wish to participate. The framework is free to use, but participants must register and agree to the TCF policies.

Key components of the TCF ecosystem

Understanding TCF requires familiarity with several components that work together:

The Global Vendor List (GVL)

IAB Europe maintains a public list of all registered vendors: ad tech companies that have agreed to the TCF policies and declared which purposes and legal bases they rely on. As of early 2026, the GVL contains over 1,200 vendors. When a CMP displays a cookie banner, it pulls information from the GVL to show users exactly which companies will process their data and for what purposes.

Consent Management Platforms (CMPs)

A CMP is the software that presents the consent interface (the cookie banner) to users. To participate in TCF, a CMP must be registered with IAB Europe and assigned a unique CMP ID. The CMP is responsible for displaying accurate, complete information, collecting user choices, encoding those choices into a TC String and making the string available to vendors via a standardised JavaScript API (the CMP API, also known as the __tcfapi).

The TC String

The TC String is a Base64-encoded string that contains all of the user's consent and legitimate interest signals, the list of vendors covered, the purposes consented to, any publisher restrictions and metadata such as the date consent was given and the CMP that collected it. This string is typically stored in a first-party cookie (often called euconsent-v2) and is passed through the ad tech chain via bid requests, pixel URLs and API calls.

The CMP API (__tcfapi)

TCF defines a JavaScript API that vendors call to check the current consent status. When a vendor's script loads on a page, it calls __tcfapi('getTCData', ...) to retrieve the TC String and determine whether it has consent to process data for its declared purposes. If consent has not been given, a well-behaved vendor should refrain from dropping cookies or collecting data.

Why your website needs TCF

The practical reality is straightforward: if you monetise your website through advertising, TCF compliance is effectively mandatory. Here is why:

  • Google requires it. Since January 2024, Google has required all publishers serving ads in the European Economic Area (EEA) and the UK to use a Google-certified CMP that supports TCF 2.2. Without it, Google may restrict or entirely block the display of personalised advertising on your site, dramatically reducing your ad revenue.
  • Major ad exchanges require it. Xandr (formerly AppNexus), Index Exchange, PubMatic, Criteo, The Trade Desk and virtually every significant player in programmatic advertising either require or strongly recommend TCF compliance from their publisher partners.
  • It demonstrates GDPR compliance. While TCF is an industry standard rather than a legal requirement per se, using a TCF-compliant CMP provides documented evidence that you collected consent in a standardised, transparent way: which is exactly what regulators expect.
  • It protects your revenue. Without valid consent signals flowing through the bid stream, advertisers will bid less (or not at all) for your inventory. Publishers who have implemented TCF correctly typically see significantly better fill rates and CPMs than those relying on non-standard consent mechanisms.

Without TCF compliance, Google may restrict or completely block the display of personalised advertising on your website: potentially cutting your ad revenue by 50% or more.

How TCF works in practice: a step-by-step walkthrough

Let us trace what happens when a user visits a TCF-compliant website for the first time:

Step 1: The CMP loads. When the page loads, the CMP script initialises and checks whether a valid TC String already exists (from a previous visit). If not, it displays the consent banner.

Step 2: The user sees the consent interface. The banner presents information about data processing purposes (pulled from the TCF purpose list) and the vendors involved (pulled from the Global Vendor List). The user can accept all, reject all, or make granular choices purpose by purpose and vendor by vendor.

Step 3: Consent is encoded. Once the user makes a choice, the CMP encodes the decisions into a TC String. This string is stored in a first-party cookie and made available through the __tcfapi JavaScript API.

Step 4: Vendor scripts check consent. As ad scripts load, each vendor calls the CMP API to retrieve the TC String and checks whether it has consent for its declared purposes. If consent exists, the vendor proceeds normally. If not, it must refrain from processing personal data.

Step 5: The TC String travels through the ad chain. When an ad request is made (e.g. a header bidding call or a request to Google Ad Manager), the TC String is included in the bid request. Every participant in the auction: SSPs, DSPs, data management platforms: can read the string and act accordingly. Advertisers who do not have consent from the user should not bid on that impression.

Step 6: Returning visitors. When the user returns, the CMP reads the existing TC String from the cookie. If it is still valid (not expired, CMP version matches, etc.), the banner is not shown again and the stored consent signals are used.

TCF purposes explained

TCF defines a fixed set of processing purposes. As of TCF 2.2, these are:

  • 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 vendor on the GVL declares which purposes it relies on and whether it uses consent or legitimate interest as its legal basis. Under TCF 2.2, legitimate interest can no longer be used for purposes 3, 4, 5 and 6: these now require explicit consent.

TCF 2.0 vs. 2.2: what changed

TCF version 2.2 was released in May 2023 and became mandatory for all participants by November 2023. The key changes were:

  • Removal of legitimate interest for certain purposes. Under TCF 2.0, vendors could claim legitimate interest for personalised advertising purposes. TCF 2.2 eliminated this, requiring consent for purposes 3 through 6. This was a direct response to criticism from regulators who argued that legitimate interest was being misused.
  • Stricter information requirements. CMPs must now display vendor names, purposes and data retention periods more prominently. The "first layer" of the consent interface must include more detail than was previously required.
  • Better user control. Users must be able to object to legitimate interest processing directly from the first layer of the consent interface, without navigating to a separate screen.
  • Vendor data retention disclosure. Vendors must declare their maximum data retention periods, and this information must be visible to users in the consent interface.
  • URL-based consent. TCF 2.2 introduced the ability to pass consent signals via URL parameters in addition to the cookie-based approach, supporting environments where cookies are restricted.

Regulatory scrutiny of TCF

It is important to note that TCF has not escaped regulatory criticism. In February 2022, the Belgian Data Protection Authority (APD) found that IAB Europe's TCF system infringed GDPR on several grounds, including that the TC String itself constituted personal data and that IAB Europe was acting as a data controller without a sufficient legal basis. IAB Europe was fined EUR 250,000 and ordered to bring TCF into compliance.

IAB Europe appealed and subsequently proposed an action plan that was provisionally approved by the APD in January 2024. The key outcome was that IAB Europe acknowledged its role as a joint controller for the TC String data and committed to implementing additional safeguards, including stricter vendor vetting and enhanced audit mechanisms.

This episode underscores a crucial point: TCF compliance alone does not guarantee GDPR compliance. TCF is a useful tool for managing consent in the advertising ecosystem, but publishers must still ensure that their overall data processing practices comply with GDPR: including having valid privacy policies, responding to data subject requests and maintaining records of processing activities.

Common TCF implementation mistakes

Even with a TCF-compliant CMP, publishers can run into problems. Here are the most common mistakes:

  • Loading vendor scripts before consent. Some publishers load ad scripts in the page header before the CMP has had a chance to collect consent. This means cookies are set and data is collected before the user has made a choice: a clear GDPR violation regardless of TCF status.
  • Not updating the GVL. The Global Vendor List is updated regularly as new vendors register and existing ones update their declarations. If your CMP is using an outdated GVL, you may be collecting consent for the wrong purposes or missing vendors entirely.
  • Ignoring publisher restrictions. TCF allows publishers to impose restrictions on vendors: for example, requiring consent rather than legitimate interest for a specific purpose. If you do not configure these restrictions, vendors may process data under legal bases you did not intend to allow.
  • Not testing the implementation. Many publishers install a CMP and assume everything is working. In practice, you should verify that the TC String is being generated correctly, that vendor scripts are checking consent before firing, and that the CMP API is accessible to all vendors on the page.

TCF and Google Consent Mode v2

If you use Google services (Analytics, Ads, AdSense), you need to understand how TCF interacts with Google Consent Mode v2. Google Consent Mode is a separate mechanism that adjusts the behaviour of Google tags based on consent status. When used alongside TCF, a properly configured CMP will update both the TC String and the Google Consent Mode signals simultaneously, ensuring that Google services behave correctly regardless of the user's consent choices.

In practice, most modern CMPs: including Consentio: handle this integration automatically. When a user consents to Purpose 1 (device storage) and Purpose 7 (ad measurement), the CMP sets both the appropriate bits in the TC String and updates the analytics_storage and ad_storage signals for Google Consent Mode.

Implementation with Consentio

Setting up TCF on your website does not have to be complicated. With Consentio, you get a cookie banner that is fully TCF 2.2 compliant and registered with IAB Europe as a certified CMP. Our platform handles all the technical complexity for you:

  • Automatic synchronisation with the Global Vendor List
  • Correct generation and storage of TC Strings
  • Full CMP API (__tcfapi) implementation
  • Integration with Google Consent Mode v2
  • Publisher restriction configuration via a simple dashboard
  • Automatic blocking of vendor scripts until consent is given

All of this is deployed with a single line of code. You focus on your content and revenue: we handle the consent infrastructure.