ConsentXDPDPA is being phased in. Scan your site to see where you stand. Scan now
ConsentXA plain-English guide to IAB TCF, the TC String, TCF v2.3, and how they relate to GDPR and cookie consent.
TCF is primarily used in the European digital advertising ecosystem. It provides standardized policies, technical specifications, consent signals, vendor information, and APIs that help participating organizations communicate users' choices about personal-data processing and device storage or access.
The current framework is TCF v2.3. It was introduced in 2025 and made the Disclosed Vendors segment a mandatory part of the TC String to address ambiguity about whether certain vendors had been disclosed to users. The transition deadline for TCF v2.3 was 28 February 2026.
IAB TCF stands for IAB Europe Transparency & Consent Framework.
It provides a common framework for the digital advertising ecosystem, including:
A typical advertising ecosystem can involve many vendors. TCF provides a standardized way to communicate information about those vendors, their declared processing purposes, applicable legal bases, and user choices.
IAB Europe describes TCF as a cross-industry voluntary standard intended to enable publishers and technology partners to work together while providing users with a standardized privacy-choice experience.
No.
The IAB Transparency & Consent Framework is an industry framework, not legislation.
It does not replace:
IAB Europe's current policies explicitly state that participation in TCF does not substitute for each participant's responsibility to comply with applicable law.
Using a TCF-compatible CMP therefore does not automatically make a website GDPR compliant.
Instead, TCF provides a standardized mechanism that can support certain privacy and advertising workflows.
The primary purpose of TCF is to create a common language for privacy choices within the digital advertising supply chain.
Consider a publisher that works with dozens of advertising and measurement vendors.
Without a standardized framework, the publisher might need to communicate privacy choices to every vendor using a different technical mechanism.
TCF standardizes important parts of this communication.
A simplified workflow is:
This can help participating organizations understand:
TCF gives people a clear way to control how ad vendors use their data. It does three things:
TCF does not stop a tracker from loading by itself, and a TC String is not legal consent on its own. To make sure a "No" really means no, you also need technical controls such as prior-script blocking and consent records.
A simplified TCF workflow is:
The publisher identifies relevant TCF vendors.
The CMP uses the current TCF policies, specifications, and GVL information.
The CMP explains relevant purposes, vendors, and other required information.
The user makes the applicable consent or objection choices.
The CMP encodes the relevant information into the TC String.
Participating vendors can access the signal through the applicable technical mechanisms.
Vendors determine the relevant processing state according to the TCF framework and their declared activities.
The website and vendors must ensure that actual processing corresponds to the applicable privacy state.
TCF v2.3 is the current version of the IAB Europe Transparency & Consent Framework.
IAB Europe launched TCF v2.3 in 2025. Its key change was to make the Disclosed Vendors section a mandatory part of the TC String.
The change was introduced to resolve ambiguity about whether certain vendors had actually been disclosed to users, particularly in scenarios involving legitimate-interest processing for Special Purposes.
The transition period ended on 28 February 2026, meaning current TCF implementations should support v2.3 rather than relying on the older v2.2 implementation.
The major TCF versions include:
TCF v2.3 should be the version referenced in current glossary content and implementation guidance.
The most important v2.3 change is the mandatory Disclosed Vendors segment.
The segment communicates whether a vendor was disclosed to the user through the CMP interface.
The technical structure includes:
IAB Tech Lab explains that the Disclosed Vendors segment provides a binary signal indicating whether a vendor was disclosed to the user.
This is particularly relevant when vendors rely on legitimate interest for certain processing activities and need to know whether the user was properly informed about their involvement.
Vendor disclosure is an important transparency requirement.
A vendor should not have to guess whether it was actually presented to the user.
TCF v2.3 provides a standardized signal to reduce that ambiguity.
The Transparency and Consent String, commonly called the TC String, is a machine-readable representation of relevant information and user choices within the TCF ecosystem.
It can communicate information relating to:
The TC String allows participating vendors to receive standardized information about the privacy state established through the CMP.
The TC String is therefore one of the most important technical components of TCF.
No.
A TC String is a technical representation of privacy information and choices.
It is not itself a legal substitute for valid consent.
Whether consent is legally valid depends on factors such as:
TCF provides technical standardization; it does not independently create the legal basis for processing.
The Disclosed Vendors segment is a key addition in TCF v2.3.
It communicates whether vendors were disclosed to the user through the relevant CMP interface.
The purpose is to remove ambiguity where vendors need to determine whether they were actually presented to the user.
This is particularly important for vendors processing data under certain legitimate-interest scenarios.
TCF v2.3 requires the Disclosed Vendors segment in TC Strings.
The Global Vendor List (GVL) is the standardized list of vendors participating in the TCF ecosystem.
It provides information that CMPs and other participants use to understand participating vendors and their declared activities.
Vendor information can include:
The GVL is important because the TC String and CMP interface need standardized vendor information.
IAB Europe's current TCF resources continue to list the GVL as a core component of the framework.
It allows CMPs and other participants to work from standardized information about participating vendors.
The GVL helps support:
The GVL is one of the core resources that make TCF's standardized vendor communication possible.
TCF uses standardized Purposes to describe why participating vendors process personal data or perform related activities.
Current TCF policies include standardized purposes such as:
The current TCF policy documentation defines these purposes and associated framework concepts.
The purpose structure is important because it provides a standardized vocabulary for CMP interfaces and vendor declarations.
Special Purposes are separate standardized processing purposes defined within TCF.
They are treated differently from ordinary Purposes and have specific requirements within the framework.
A website should therefore not simplify TCF into:
"The user accepts or rejects cookies."
TCF covers a broader advertising and data-processing ecosystem involving purposes, vendors, features, special purposes, and legal bases.
TCF also defines Features and Special Features.
These describe specific capabilities or characteristics associated with vendor processing.
Special Features receive additional treatment under TCF policies.
The distinctions matter because a TCF CMP must present and communicate the relevant information according to the current framework requirements rather than treating every vendor activity as a generic cookie.
TCF has historically supported multiple legal-basis concepts, including consent and legitimate interest.
However, the framework has changed substantially over time.
TCF v2.2 removed legitimate interest as a legal basis for Purposes 3–6.
TCF v2.3 then introduced the mandatory Disclosed Vendors segment to resolve ambiguity around whether vendors were disclosed to users in certain legitimate-interest scenarios.
A vendor's declaration of legitimate interest does not mean that it automatically has unrestricted permission to process personal data.
The applicable law and the specific processing activity remain important.
A TCF CMP is a Consent Management Platform participating in the IAB Europe TCF ecosystem.
A TCF CMP can provide the user-facing and technical infrastructure needed to:
A normal cookie banner is not automatically a TCF CMP.
TCF participation involves specific registration, policy, technical, and compliance requirements.
TCF and CMP are related, but they are not the same thing.
| TCF | CMP |
|---|---|
| Industry framework | Software/platform |
| Defines policies and standards | Implements privacy-choice workflows |
| Defines standardized purposes and vendor concepts | Presents information to users |
| Defines technical signaling mechanisms | Generates and communicates signals |
| Defines participation requirements | Provides the implementation |
| Managed by IAB Europe with technical collaboration | Provided by individual CMP companies |
In simple terms:
A TCF CMP typically handles several stages of the consent process.
The CMP explains relevant purposes, vendors, and processing activities.
The user can make applicable consent or preference choices.
The CMP generates the appropriate TC String.
The CMP makes the relevant signal available to participating vendors.
The user can later modify or withdraw applicable choices.
The broader website implementation should ensure that actual processing corresponds with the resulting privacy state.
That final point is critical.
Generating a TC String is not the same as preventing unauthorized processing.
The Global Privacy Platform (GPP) is a broader privacy-signal framework developed by IAB Tech Lab.
TCF and GPP are related but are not the same thing.
A simplified distinction is:
European Transparency & Consent Framework
broader privacy-signal framework supporting multiple jurisdictions
GPP can carry a TCF section alongside regional privacy sections.
Therefore, an organization operating internationally may use TCF within a broader GPP architecture.
| TCF | GPP |
|---|---|
| IAB Europe framework | IAB Tech Lab framework |
| Primarily European advertising ecosystem | Multi-jurisdiction privacy signaling |
| Uses the TC String | Uses GPP strings/sections |
| Standardizes European vendor and purpose information | Supports multiple regional privacy frameworks |
| Strongly associated with GDPR/ePrivacy advertising workflows | Designed for broader privacy-regulation signaling |
TCF and GPP should therefore not be treated as interchangeable terms.
IAB TCF and Google Consent Mode solve different problems.
TCF standardizes privacy-choice signaling within the TCF ecosystem.
Google Consent Mode communicates relevant consent states to supported Google tags and services so that their behavior can adjust according to those states.
A publisher can use both:
and:
The technologies can therefore be complementary rather than competing alternatives.
Global Privacy Control (GPC) is a browser-level or privacy-tool signal that communicates certain opt-out preferences.
TCF is an advertising-industry framework for transparency and consent signaling.
They serve different purposes.
A website may have both:
within the same privacy architecture.
A cookie-consent banner is primarily a user interface.
TCF is a standardized industry framework that governs privacy-choice communication within its ecosystem.
A simplified architecture can therefore be:
The banner is what the user interacts with.
The TCF framework provides the standardized policies and technical mechanisms behind the ecosystem.
TCF was built for the European advertising ecosystem. It supports, but never replaces, the laws below.
If you sell ads in several regions, TCF can sit inside IAB's Global Privacy Platform (GPP), which carries signals for more than one jurisdiction.
Remember: TCF is not legal advice, and using it does not make a website compliant by itself.
No.
TCF can support parts of a privacy and advertising compliance workflow, but it is not a GDPR compliance certificate.
IAB Europe's own policies explicitly state that participation in TCF is not a substitute for individual participants taking responsibility for their legal obligations.
A broader GDPR compliance program may also require:
No.
TCF is primarily a framework for standardized transparency and signaling.
It does not automatically prevent every cookie or tracker from loading.
A website may need additional enforcement mechanisms such as:
For example, a CMP might correctly generate a TC String showing that a user has not consented to a purpose while a poorly configured tag still fires.
That would be an implementation problem.
Prior consent and TCF are related but different concepts.
Prior consent means that consent is obtained before applicable processing or device access takes place: in practice, consent before any tracker loads.
TCF provides standardized signaling after or as part of the privacy-choice process.
A simplified workflow may look like:
The exact sequence depends on the website's technical architecture and applicable law.
TCF is particularly important for programmatic advertising.
A publisher may work with many advertising and measurement vendors, including:
TCF gives these participants a standardized mechanism for communicating relevant privacy information.
This is one of the main reasons TCF is particularly valuable to publishers and media businesses.
Publishers using programmatic advertising may need to manage:
IAB Europe specifically identifies publishers, CMPs, and vendors as core TCF participants.
A TCF vendor is a technology provider participating in the framework.
Vendors may include:
A participating vendor uses TCF signals to understand the privacy state relevant to its declared processing.
However, vendors remain responsible for their own compliance obligations.
The TCF CMP API is a standardized technical interface that allows participating vendors and other components to interact with a TCF CMP.
The API supports functions related to:
TCF technical specifications and implementation guidelines define the applicable API behavior. IAB Europe's current supporting-resources page lists the CMP API as a core TCF technical specification.
TCF technical specifications have evolved.
The TCF v2.2 CMP API deprecated the getTCData command.
Developers maintaining older TCF integrations should therefore review current implementation guidance rather than assuming legacy API patterns remain appropriate.
This is particularly important when updating older TCF v2.2 integrations for the current v2.3 environment.
Before launching or updating a TCF implementation, publishers should verify:
IAB Europe maintains current TCF supporting resources covering policies, technical specifications, implementation guidelines, CMP registration, vendor registration, and v2.3 resources.
Treating TCF as GDPR compliance
TCF is an industry framework, not a legal compliance certificate.
Leaving the website on TCF v2.2
Current implementations should be reviewed against TCF v2.3.
Treating the TC String as consent itself
The TC String represents technical information about privacy choices. It does not independently create legally valid consent.
Loading trackers before consent
A website still needs appropriate technical controls for processing that requires prior consent.
Ignoring vendor behavior
Generating a correct TC String is not enough if vendors continue processing contrary to the resulting state.
Treating legitimate interest as unlimited permission
A vendor's declared legal basis does not eliminate the organization's obligation to comply with applicable law.
Using obsolete API code
Older TCF integrations may contain deprecated API methods such as getTCData.
Failing to maintain vendor information
Vendor information and framework requirements can change.
Testing only "Accept All"
A serious TCF implementation should also test rejection, partial choices, withdrawal, returning users, and regional configurations.
A proper TCF audit should examine both the CMP interface and the actual technical behavior. To see what really loads, scan your site for cookies and trackers.
Test:
Test:
Also test:
A TC String only reports what a user chose. It does not stop a tracker from running. ConsentX closes that gap, so what the user chose is what actually happens on your site:
Does ConsentX replace IAB TCF? No. TCF is the industry framework. ConsentX is the consent platform that helps you manage choices and enforce them on your site.
At ConsentX, we believe a privacy choice only counts if your website respects it. A TC String can tell vendors what a user chose, but it cannot stop a tracker on its own. That is why ConsentX focuses on making consent real: users get clear choices, trackers wait for permission, and you keep proof of every decision.
What you get:
Not sure if your site respects your users' choices? Scan your site, Start Free or Book a Demo.
Explore ConsentX