The IAB TCF works as a consent-signal relay. A CMP asks a visitor which purposes and vendors they allow. It encodes the answer into a TC string and passes that string down the ad-tech chain.
Below: the framework's building blocks, the signal's step-by-step journey from banner to ad request, a full worked example, and what changed in the current version.
How Does the IAB TCF Work? (The Short Answer)
The IAB TCF works by turning a visitor's consent choice into a portable, machine-readable signal. A CMP collects the choice and encodes it into a TC string. Every downstream vendor, from the publisher's ad server to the winning bidder, reads that same string before it processes the visitor's data.
The framework runs on four parts. A Consent Management Platform (CMP) sits on the publisher's site and does the actual asking. The Global Vendor List (GVL), maintained by IAB Europe, tells the CMP which vendors and purposes exist to ask about. The visitor's choice becomes a TC string, a compact encoded record the CMP exposes through a standard JavaScript interface. Every vendor and demand-side platform (DSP) downstream reads that string instead of asking the visitor again.
That single string is what makes the framework work at scale. A publisher running dozens of ad-tech vendors does not need each vendor to build its own consent UI. It collects consent once and lets the string carry that decision through the entire programmatic chain.
The Building Blocks: CMP, Global Vendor List, Purposes, and the TC String
Four components make the TCF function. The CMP runs the interaction and the GVL supplies the vendor and purpose data. The Purposes classify what consent covers, and the TC string carries the result.
The Consent Management Platform (CMP)
A CMP is the software that runs the entire consent mechanism on a publisher's site. It fetches the current Global Vendor List, renders the consent banner, and captures the visitor's choice. It then encodes that choice into a TC string and exposes it through the framework's standard API.
A publisher's own CMP setup illustrates the mechanism directly. One publisher explained it while working through their disclosure setup:
Our own CMP fetches the current IAB GVL (global vendors list) and asks the user for permission for each Vendor listed on the GVL.
The CMP is the only component a visitor actually interacts with. Every other part of the framework operates behind that single banner. For the category-level definition of what a consent management platform does beyond IAB TCF specifically, see what a consent management platform does.
The Global Vendor List (GVL)
The Global Vendor List is the IAB-maintained registry of every ad-tech vendor participating in the TCF. A CMP fetches the current GVL to know which vendors and purposes exist before it can ask a visitor anything.
The live Global Vendor List, fetched directly from IAB Europe's registry, lists 1,188 registered vendors. It runs on vendor list version 166, last updated July 2, 2026. Each vendor entry declares which purposes, special purposes, and features it uses, and whether it relies on consent or legitimate interest for each one.
The GVL updates on a rolling basis as vendors register, update their declarations, or get removed. A CMP that caches an outdated copy risks showing visitors a vendor list that no longer matches what actually runs on the site.
Purposes, Special Purposes, and Features
The TCF classifies every use of a visitor's data into a fixed set of Purposes, Special Purposes, and Features. The current Global Vendor List defines 11 Purposes and 3 Special Purposes.
The 11 standard Purposes, verified against the live GVL (specification version 3, policy version 5):
- 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
- Understand audiences through statistics or combinations of data from different sources
- Develop and improve services
- Use limited data to select content
A visitor can consent to or refuse each Purpose individually. Special Purposes work differently. They cover operations the framework treats as necessary to running the system itself, so they run on legitimate interest rather than visitor consent. A visitor cannot object to a Special Purpose the same way they refuse a Purpose.
The current GVL defines three Special Purposes.
- Ensure security, prevent and detect fraud, and fix errors.
- Deliver and present advertising and content.
- Save and communicate privacy choices.
That third entry, Special Purpose 3, is named in the live GVL and the framework's official IAB Europe policies.
Special Purpose 3 is the newest and least-explained piece of the current framework. It gives vendors a legal basis for processing the privacy choice itself. A TC string containing a visitor's consent decisions is personal data once it identifies that visitor. Storing and forwarding it needs its own declared basis.
The TC String (the Transport Layer)
The TC string is a compact, encoded record of a visitor's per-purpose and per-vendor consent decisions. It is what actually moves through the ad-tech chain; every other component exists to produce or consume it.
One open-source CMP implementation describes the exact runtime interface that exposes the string.
The implementation covers the full CMP API (the __tcfapi stub and the consent string encoding) via a dedicated tcf-cmp.js.
Any script on the page calls that same interface to read the current string. This applies whether the script belongs to the publisher's own tag or a third-party vendor's, and it never re-asks the visitor.
The string itself carries no personal identifiers beyond the consent decisions. It is a state record, not a tracking mechanism. For the bit-level detail of how the string encodes each decision, see how the TC string encodes consent.
How the IAB TCF Works Step by Step
Here is the consent signal's full journey, from page load to ad render.
Step 1: The CMP Loads and Fetches the Global Vendor List
The CMP script loads before any tracking or advertising script. It immediately pulls the current Global Vendor List from IAB Europe's registry. That list tells it which vendors and purposes to disclose before it renders the banner.
Step 2: The Banner Discloses Purposes and Vendors to the Visitor
The first banner layer shows the total number of disclosed vendors and the purposes they use. A second, granular layer lets the visitor control consent per purpose and per vendor.
Publishers do not need to disclose every vendor on the GVL. IAB guidance is explicit: publishers should "disclose only vendors and purposes that are relevant to their site/app," not the full 1,188-vendor registry.
Step 3: The Visitor Makes a Choice
The visitor accepts everything, rejects everything, or sets granular per-purpose and per-vendor preferences. Before any choice is made, the default state is all-false, so every vendor receives a signal that authorizes only non-personalized processing.
Rejecting all does not grant vendors legitimate interest for advertising purposes. That legal basis was removed from advertising purposes in TCF v2.2 and stays removed in v2.3.
Step 4: The CMP Encodes the Choice into a TC String
The CMP compresses every per-purpose and per-vendor decision into a single TC string. It stores that string in the browser, typically in a cookie or local storage.
In the current version, the CMP also writes a Disclosed Vendors segment into that string. This mandatory v2.3 addition records exactly which vendors the publisher disclosed to the visitor.
Step 5: The TC String Is Exposed Through the CMP API (__tcfapi)
This step answers the question that trips up most people trying to understand the mechanism: how does a script actually read the string. Any script on the page calls the standard __tcfapi('getTCData', ...) JavaScript function to retrieve the current consent state at runtime.
The CMP is the only party that writes the string. Every other vendor script only reads it through this same interface.
Step 6: The Publisher Passes the TC String Down the Ad-Tech Chain
The string travels with the ad request itself. A prebid or header-bidding module attaches the current TC string to each bid request. It then sends that request to a supply-side platform (SSP), which forwards it into the real-time bidding stream.
One practitioner working through this exact flow described the pattern:
CMP generates consent string with default settings. CMP module in prebid checks it. Sends requests to SSP (requests should contain consent string). SSP responds, displaying ads.
Google Ad Manager follows the same pattern automatically. It passes the TC string to Google's programmatic channels without requiring the publisher to configure anything extra.
Step 7: Vendors and DSPs Read the String and Act on It
Each vendor and demand-side platform (DSP) reads the incoming TC string. It checks its own listed purposes and legal bases against that string before it decides how to process the request.
A vendor without consent for personalized-advertising purposes serves a non-personalized ad or drops out of the auction entirely. A vendor covered under a Special Purpose, like fraud prevention, still runs regardless of the visitor's Purpose-level choices. Some vendors are not yet registered on the GVL, mostly a handful of Google ad partners. Those get handled through a separate bridge called Additional Consent, not through the TCF string itself.
The IAB TCF in Practice: A Programmatic Ad Request, End to End
Consider a mid-sized EU news publisher running Google Ad Manager alongside a prebid header-bidding setup, with an IAB-listed CMP installed.
A visitor in Germany opens an article. The CMP has already fetched the current GVL and shows a banner disclosing 42 vendors relevant to this site, grouped under the 11 standard Purposes. The visitor accepts analytics purposes but rejects Purpose 3 (create profiles for personalised advertising) and Purpose 4 (use profiles to select personalised advertising).
The CMP encodes this choice into a TC string, including the mandatory Disclosed Vendors segment listing all 42 disclosed vendors. It stores that string in the browser.
When the page requests an ad, prebid's consent-management module reads the string via __tcfapi and attaches it to every bid request it sends out. A demand-side platform that needs Purpose 3 and 4 consent to run its personalized-ad model sees the rejection in the string. It either bids non-personalized or does not bid at all. A vendor covered only under Special Purpose 1, security and fraud prevention, still processes the request regardless of the visitor's rejection. That purpose never required consent in the first place.
The measurable consequence: personalized-ad fill for this visitor drops, and the auction resolves with contextual, non-personalized inventory instead. The publisher's CPM on this impression runs lower than a fully-consented visitor's would. The auction still completes and the ad still renders, because the framework's job is to route consent accurately, not to block advertising outright.
How CMP Registration and Validation Keep the Signal Trustworthy
A TC string is only trustworthy because only a registered CMP can mint one that vendors will honor. That CMP must be listed on the IAB CMP List.
To register, a CMP applies to IAB Europe. IAB Europe verifies the identity of the party controlling the CMP before it approves anything. It also confirms that CMP can maintain its service and follow the framework's policies.
Each approved CMP receives a CMP ID that appears inside every TC string it generates. A vendor reading the string can trace it back to a known, accountable source this way. A malformed or unrecognized TC string, one from an unregistered CMP or a broken implementation, gets rejected by downstream ad platforms. Publishers who see AdSense consent-string errors are usually looking at exactly this failure mode.
Google adds a further requirement on top of IAB registration. To serve personalized ads in the EEA and UK, a publisher's CMP must also be Google-certified for TCF v2.3, not just IAB-listed.
Whether the framework itself is legally sufficient under GDPR has also been challenged in EU regulatory proceedings. That legal question belongs to what the IAB TCF is, which covers it in full.
What Changed in TCF v2.3, and Why the Version Matters
The IAB TCF's current version is v2.3. This is confirmed directly against the live Global Vendor List, which reports specification version 3 and policy version 5 as of this writing.
The single most consequential mechanism change in v2.3 is the mandatory Disclosed Vendors segment. Every TC string a CMP generates must now include a binary record of exactly which vendors were disclosed to that visitor. This closes a gap where a vendor could claim consent it was never actually shown for.
The version also clarifies the legal basis for Special Purposes processed under legitimate interest. It formalizes Special Purpose 3, giving vendors a defined basis for processing the privacy choice itself as the personal data it legally is. IAB Tech Lab stewards the technical specification and its GDPR TCF standard alongside IAB Europe's policy layer.
Some vendor documentation and older CMP pages still reference TCF v2.2. Even reputable sources disagree on the exact date v2.3 became mandatory. Some cite a February 28, 2026 enforcement deadline; others describe a March 1, 2026 transition. Both dates are now in the past. The authoritative signal is not any single vendor's changelog; it is the live GVL itself, which is already generating v2.3-format vendor lists.
The version history: v1.1 (2018), v2.0 (2020), v2.2 (2023), v2.3 (2026).
FAQs
What is the current version of the IAB TCF?
The current version is v2.3, verified directly against the live Global Vendor List (specification version 3, policy version 5). Some vendor pages and older documentation still reference v2.2; the GVL itself is the authoritative source.
How many purposes does the IAB TCF define?
The current framework defines 11 standard Purposes and 3 Special Purposes, plus 3 Features and 2 Special Features, all verified against the live GVL.
What is the difference between a purpose and a special purpose?
A Purpose requires the visitor's consent, or in limited cases legitimate interest, and the visitor can refuse it. A Special Purpose, like fraud prevention or saving the visitor's own privacy choices, runs on legitimate interest and cannot be refused the same way.
Does rejecting consent stop every vendor?
No. A rejection still leaves Special Purposes running, such as security and fraud prevention. A vendor without consent can still serve non-personalized content where its own setup supports that.
Should a publisher list every vendor on the Global Vendor List?
No. IAB guidance is explicit that a publisher discloses only the vendors and purposes relevant to its own site. The full registry runs over a thousand GVL vendors.
Is the TC string a cookie?
No. The TC string is an encoded consent record, typically stored inside a cookie or local storage. It is the record itself, not the storage mechanism. It communicates a visitor's choices; enforcing those choices is each vendor's own responsibility.
How is the IAB TCF different from Google Consent Mode?
The IAB TCF passes a granular, per-vendor and per-purpose consent string through the entire ad-tech chain so every vendor can read the same signal. Google Consent Mode is a narrower signal that adjusts how Google's own tags behave based on the visitor's choice. The two are complementary, not interchangeable.
Do Google and Meta use the IAB TCF?
Google supports the IAB TCF and requires a Google-certified TCF v2.3 CMP to serve personalized ads in the EEA and UK. Meta does not participate in the IAB TCF the same way; it handles consent signaling through its own mechanism outside the framework.
Understanding how the IAB TCF works is only useful once you also know when to use it. Publishers running opt-in regimes handle the signal differently than sites relying on opt-in versus opt-out consent models outside the EU.
Consently's IAB TCF support runs the CMP side of this framework for publishers who want to put the mechanism into practice. It handles everything from fetching the GVL to minting a valid TC string on every page load.
