What is the IAB Transparency & Consent Framework (TCF)?
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.
What does IAB TCF mean?
IAB TCF stands for IAB Europe Transparency & Consent Framework.
It provides a common framework for the digital advertising ecosystem, including:
- Publishers
- Media companies
- Advertisers
- Advertising agencies
- Consent Management Platforms
- Ad-tech vendors
- Demand-side platforms (DSPs)
- Supply-side platforms (SSPs)
- Ad servers
- Measurement providers
- Other technology partners
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.
Is IAB TCF a law?
No.
The IAB Transparency & Consent Framework is an industry framework, not legislation.
It does not replace:
- GDPR
- The ePrivacy Directive
- UK GDPR
- National privacy laws
- Regulatory guidance
- Court decisions
- Other applicable data-protection requirements
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.
What is the purpose of the IAB TCF?
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:
- User
- CMP
- TCF signal
- Advertising vendors
- Processing
This can help participating organizations understand:
- Which vendors are involved
- What purposes vendors declare
- Which legal bases are being used within the framework
- What choices the user made
- Which vendors were disclosed
- Which publisher restrictions apply
- How the user's privacy state should be communicated
What is TCF v2.3?
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.
TCF version history
The major TCF versions include:
- TCF v1.12018
- TCF v2.02019
- TCF v2.12020
- TCF v2.22023
- TCF v2.32025
TCF v2.3 should be the version referenced in current glossary content and implementation guidance.
What changed in TCF v2.3?
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:
- Core segment
- Disclosed Vendors segment
- optional Publisher TC segment
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.
Why this matters
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.
What is a TC String?
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:
- User consent
- User objections
- Vendors
- Purposes
- Legal bases
- Publisher restrictions
- Disclosed vendors
- Framework metadata
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.
Is the TC String the same as consent?
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:
- What information was provided
- Whether the choice was freely made
- Whether the purpose was sufficiently specific
- Whether the user actively indicated consent where required
- Whether withdrawal is possible
- Whether the applicable legal requirements are satisfied
- Whether the actual processing matches the disclosed processing
TCF provides technical standardization; it does not independently create the legal basis for processing.
What is the Disclosed Vendors segment?
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.
What is the Global Vendor List (GVL)?
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:
- Vendor ID
- Vendor name
- Declared purposes
- Special purposes
- Features
- Special features
- Legal bases
- Data categories
- Other framework information
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:
- Vendor identification
- Purpose declarations
- Special-purpose declarations
- Feature information
- Legal-basis information
- Vendor disclosures
The GVL is one of the core resources that make TCF's standardized vendor communication possible.
What is a TCF CMP?
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:
- Present privacy information.
- Disclose applicable vendors and purposes.
- Collect user choices.
- Generate the TC String.
- Make the signal available to participating vendors.
- Support the applicable CMP API.
- Manage preference changes.
- Support the relevant TCF policies and specifications.
A normal cookie banner is not automatically a TCF CMP.
TCF participation involves specific registration, policy, technical, and compliance requirements.
TCF vs CMP
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:
- TCF is the framework.
- A CMP is the software that can implement the framework.
What does a TCF CMP do?
A TCF CMP typically handles several stages of the consent process.
Transparency
The CMP explains relevant purposes, vendors, and processing activities.
Choice
The user can make applicable consent or preference choices.
Signal generation
The CMP generates the appropriate TC String.
Signal availability
The CMP makes the relevant signal available to participating vendors.
Preference management
The user can later modify or withdraw applicable choices.
Technical enforcement
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.
What are TCF Purposes?
TCF uses standardized Purposes to describe why participating vendors process personal data or perform related activities.
Current TCF policies include standardized purposes such as:
- Store and/or access information on a device
- Use limited data to select advertising
- Create profiles for personalised advertising
- Use profiles to select personalised advertising
- Create profiles to personalise content
- Use profiles to select personalised content
- Measure advertising performance
- Measure content performance
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.
What are Special Purposes?
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.
What are TCF Features and Special Features?
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.
Consent and legitimate interest in TCF
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.
Does TCF mean a user has given consent?
No.
TCF is a framework for transparency and privacy-choice signaling.
It does not independently create valid consent.
A compliant consent workflow still needs to satisfy applicable legal requirements.
For example, where consent is the legal basis, the organization should consider whether the consent is:
- Freely given
- Specific
- Informed
- Unambiguous
- Based on appropriate information
- Withdrawable
The actual user interface and technical behavior must also correspond to the claimed legal basis.
Does TCF make a website GDPR compliant?
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:
- Privacy notices
- Valid consent mechanisms
- Lawful-basis analysis
- Cookie and tracker controls
- Data-subject rights
- Data minimization
- Data retention
- Vendor management
- Data-processing agreements
- Security controls
- International-transfer safeguards
- Records of processing
- Governance and accountability
TCF and GDPR
TCF was created specifically in response to the European privacy environment and is intended to help participating organizations address certain GDPR and ePrivacy requirements in the digital advertising ecosystem.
IAB Europe describes TCF as an accountability tool intended to facilitate compliance with certain provisions of the GDPR and ePrivacy Directive.
However:
Organizations remain responsible for determining their own legal obligations.
TCF and the ePrivacy Directive
TCF is also relevant to the ePrivacy Directive, particularly for technologies that store or access information on users' devices.
This means European advertising compliance can involve multiple legal layers:
personal-data processing
device storage/access and related technologies
standardized industry signaling and accountability framework
TCF does not replace either legal framework.
Does TCF block cookies?
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:
- Prior-script blocking
- Tag-management controls
- Cookie controls
- CMP integrations
- Vendor blocking
- Server-side controls
- Consent-state propagation
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.
TCF and prior consent
Prior consent and TCF are related but different concepts.
Prior consent means that consent is obtained before applicable processing or device access takes place.
TCF provides standardized signaling after or as part of the privacy-choice process.
A simplified workflow may look like:
- User visits
- CMP loads
- privacy information appears
- user chooses
- applicable consent state established
- permitted technologies activate
- TC String communicated
The exact sequence depends on the website's technical architecture and applicable law.
TCF and programmatic advertising
TCF is particularly important for programmatic advertising.
A publisher may work with many advertising and measurement vendors, including:
- SSPs
- DSPs
- Ad exchanges
- Ad servers
- Measurement providers
- Audience platforms
- Verification providers
- Data providers
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.
TCF for publishers
Publishers using programmatic advertising may need to manage:
- Vendor disclosures
- Purpose disclosures
- User consent
- User objections
- Publisher restrictions
- TC String generation
- CMP configuration
- Vendor integrations
- Consent withdrawal
- Tracker activation
- Privacy compliance
IAB Europe specifically identifies publishers, CMPs, and vendors as core TCF participants.
TCF for vendors
A TCF vendor is a technology provider participating in the framework.
Vendors may include:
- Advertising platforms
- Measurement providers
- DSPs
- SSPs
- Ad servers
- Audience providers
- Other ad-tech companies
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.
What is the TCF CMP API?
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:
- CMP availability
- Consent information
- TC String retrieval
- Consent updates
- Privacy-state communication
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.
What happened to getTCData?
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.
What is GPP and how does it relate to TCF?
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 vs GPP
| 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.
TCF vs Google Consent Mode
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:
- CMP
- TCF / TC String
and:
- CMP
- Google Consent Mode
The technologies can therefore be complementary rather than competing alternatives.
TCF vs GPC
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:
- GPC
- TCF
- CMP
- Cookie consent
- Google Consent Mode
- Regional privacy rules
within the same privacy architecture.
TCF vs cookie consent
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:
- Cookie banner
- TCF CMP
- TC String
- participating vendors
The banner is what the user interacts with.
The TCF framework provides the standardized policies and technical mechanisms behind the ecosystem.
How does IAB TCF work?
A simplified TCF workflow is:
Identify participating vendors
The publisher identifies relevant TCF vendors.
Configure the CMP
The CMP uses the current TCF policies, specifications, and GVL information.
Present transparency information
The CMP explains relevant purposes, vendors, and other required information.
Capture the user's choices
The user makes the applicable consent or objection choices.
Generate the TC String
The CMP encodes the relevant information into the TC String.
Make the signal available
Participating vendors can access the signal through the applicable technical mechanisms.
Vendors interpret the signal
Vendors determine the relevant processing state according to the TCF framework and their declared activities.
Enforce the resulting state
The website and vendors must ensure that actual processing corresponds to the applicable privacy state.
IAB TCF implementation checklist
Before launching or updating a TCF implementation, publishers should verify:
- The CMP supports the current TCF version.
- The CMP is appropriately registered for TCF participation.
- Current TCF policies are being followed.
- Current technical specifications are being used.
- Vendor information is synchronized with the applicable GVL.
- The correct TCF purposes are disclosed.
- Relevant vendors are disclosed.
- The Disclosed Vendors segment is implemented correctly.
- Consent is collected through appropriate user action.
- Applicable legitimate-interest processing is handled correctly.
- Publisher restrictions are configured where needed.
- The correct TC String is generated.
- Vendors can retrieve the relevant signal.
- Trackers do not activate contrary to the user's choices.
- Consent withdrawal works correctly.
- Vendor integrations have been tested.
- CMP API behavior has been tested.
- The implementation has been tested after framework updates.
IAB Europe maintains current TCF supporting resources covering policies, technical specifications, implementation guidelines, CMP registration, vendor registration, and v2.3 resources.
Common IAB TCF implementation mistakes
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.
How should TCF be tested?
A proper TCF audit should examine both the CMP interface and the actual technical behavior.
User-interface testing
Test:
- Initial notice
- Vendor disclosures
- Purpose disclosures
- Accept controls
- Reject controls
- Preference centre
- Withdrawal
- Mobile display
- Accessibility
- Localization
Technical testing
Test:
- TC String generation
- CMP API
- Vendor signal propagation
- Cookies
- JavaScript execution
- Network requests
- Advertising pixels
- Third-party requests
- Consent-state changes
- Withdrawal
Negative testing
Also test:
- Reject all
- Partial consent
- Vendor-specific rejection
- Purpose-specific rejection
- No interaction
- Withdrawal
- Returning users
- Different regions
- Different browsers
- Mobile devices
IAB TCF and ConsentX
ConsentX can act as the consent-management and enforcement layer within a broader privacy architecture.
For organizations using TCF, the desired workflow is:
- User choice
- CMP
- TCF signal
- vendor controls
- actual processing
ConsentX can help connect consent management with technical enforcement across areas such as:
Cookie consent
Prior-script blocking
Consent records
Audit evidence
Regional privacy rules
Google Consent Mode
Global Privacy Control
Vendor and tracker controls
Privacy preference management
The important principle is:
Consent signaling should be accompanied by technical enforcement.
A TC String that says a user has not granted a particular permission should not be treated as sufficient if the website continues performing the corresponding processing.
Does ConsentX replace IAB TCF?
No.
IAB TCF and ConsentX serve different roles.
TCF is the industry framework containing policies, specifications, technical signaling, and participation requirements.
ConsentX is a consent-management platform that can provide the user-facing and technical controls needed to manage privacy choices.
Organizations using TCF should evaluate whether their CMP implementation meets the applicable TCF participation and technical requirements.
Key takeaways
- IAB TCF means IAB Europe Transparency & Consent Framework.
- TCF is a voluntary industry framework, not a law.
- It standardizes privacy-choice communication within the digital advertising ecosystem.
- TCF v2.3 is the current framework version.
- TCF v2.3 introduced a mandatory Disclosed Vendors segment in the TC String.
- The TC String communicates standardized information about privacy choices.
- The Global Vendor List (GVL) provides standardized information about participating vendors.
- A TCF CMP implements the applicable consent-management workflow.
- TCF is especially important for publishers and programmatic advertising.
- TCF does not automatically make a website GDPR compliant.
- TCF does not itself block cookies or trackers.
- TCF is different from GPC, GPP, Google Consent Mode, and a generic cookie banner.
- Current implementations should be tested against the latest TCF policies and technical specifications.
- Effective implementation requires both correct signaling and actual technical enforcement.
Pair TCF signalling with technical enforcement
Consent signaling should be accompanied by technical enforcement. ConsentX can act as the consent-management and enforcement layer within a broader privacy architecture, connecting cookie consent, prior-script blocking, consent records, regional privacy rules and vendor controls with the signals your CMP generates.