What is the IAB TCF?

The IAB TCF is a standard technical format, developed jointly by IAB Europe and IAB Tech Lab, so that websites and apps show in a uniform way what consent a user has given and pass it on to the advertising partners involved in delivering an ad. It is not a law and not an official certification from any regulator. It is an advertising industry agreement on how to encode and share that information among everyone involved in an ad auction.

It is worth separating the TCF from a CMP (consent management platform). The CMP is the software installed on the site, the banner the user sees and uses to accept or reject categories of data processing. The TCF is the standard that defines how that CMP must generate and structure the consent signal so it can be read by any advertising provider in the ecosystem. A website can have a CMP installed without complying with the TCF, and in fact many CMPs on the market offer both modes at the same time.

The official TCF specification exists only in English. IAB Europe does not publish a translated version in Spanish or German, so any direct technical query about the standard ends up pointing to the English-language documentation.

The core element of the TCF is the TC String (Transparency & Consent String), an encoded string that records, for a given user, which processing purposes and which specific vendors they have consented to or legitimately objected to. That string is not readable at a glance: it follows a compressed binary format that is only decoded with specific tools.

For the TC String to make sense across the whole ecosystem, the TCF maintains the Global Vendor List (GVL), a public registry of all registered advertising vendors, each with a fixed numeric identifier. When the CMP builds the TC String, it marks the GVL identifiers that correspond to the vendors the user has accepted.

The string's journey has three steps. First, the CMP generates it in the browser or app when the user interacts with the consent banner. Second, the publisher, the website or app, stores it, usually in a cookie or local storage, and exposes it through the TCF's technical framework so any script on the page can read it. Third, each ad-tech vendor participating in the programmatic auction, whether an SSP, a DSP or an exchange, checks that string before deciding whether it can bid to show a personalized ad to that specific user, and for which purposes.

If a vendor does not find its identifier among the accepted ones in the TC String, the specification requires treating that user, for that vendor specifically, as if they had not given consent, even if they accepted other vendors in the same string.

The TC String decides something very concrete: whether a programmatic advertising vendor can target that user with personalized ads, measure their behavior, or share their data with third parties. Without a valid signal, the specification requires treating them as a user without consent, which directly reduces the demand inventory available to that publisher.

This has become more demanding with version 2.3. IAB Europe published TCF v2.3 on 19 June 2025, with a transition period that concluded on 28 February 2026. Since 1 March 2026, any TC String created without the mandatory disclosedVendors segment is considered invalid. Compliant strings generated before that date remain valid until the user changes their choice.

The difference matters because the disclosedVendors segment does not describe how the consent process works, but instead provides a machine-readable technical proof of which specific vendors the CMP actually showed the user at the moment consent was requested. Previously it was enough to explain the process. Now the TC String itself has to demonstrate it.

• Check whether the installed CMP already declares TCF version 2.3 and generates the disclosedVendors segment in every new TC String it issues, with no exception by device type.
• Decode a sample of TC Strings generated after 1 March 2026 and verify that the disclosedVendors segment is present and contains the vendors that actually appeared in the banner.
• Cross-check the vendor list configured in the CMP against the current Global Vendor List, since IAB Europe updates it fairly regularly and a removed or renamed vendor can break the signal without any visible warning.
• Confirm with each advertising partner, SSP, DSP or exchange, that its integration reads the current TC String and not an earlier version of the framework that does not recognize the new segment.
• Ask the CMP provider for written confirmation that its specific implementation complies with TCF v2.3, and keep that confirmation on file as evidence of compliance.
• Review compliance periodically, since IAB Europe keeps publishing updates to the specification, and a CMP that is compliant today can stop being so with the next revision.

• Assuming that every user's consent has to be re-collected on 1 March 2026. Valid TC Strings generated before that date remain valid until the user changes their choice.
• Confusing the CMP with the TCF and assuming that installing any consent banner already meets the standard, without checking which framework version it actually implements.
• Not checking whether the advertising partners in the chain actually read and honor the TC String, and continuing to treat the user as if they had not given consent even when they had.
• Treating the explanation of the consent process as if it were equivalent to the technical proof required by the disclosedVendors segment, when the two are not the same thing.
• Working with an outdated Global Vendor List and leaving active vendors undeclared in the TC String, which invalidates the signal for those specific vendors.