IAB TCF v2.3: What your website needs to communicate to advertising partners

Does your website need TCF?

TCF is most relevant when your advertising or publishing partners require it, particularly in programmatic advertising. It can also matter to advertisers using participating technology providers.

It is not a general legal requirement for every European website. A small business using a contact form and a limited analytics setup should first identify its actual partner requirements. Avoid adding a large vendor list without a business reason.

The IAB Europe framework overview explains the framework’s role. Treat it as an industry mechanism used alongside applicable privacy and cookie law.

What changed with v2.3?

The main technical change is a mandatory Disclosed Vendors segment in the Transparency and Consent string, usually called the TC string. It records the vendors disclosed to the user, helping recipients distinguish disclosure from other permissions.

A vendor appearing in this segment has not automatically received consent. Disclosure, consent and the conditions for relying on legitimate interests remain different questions.

The v2.3 transition period ended in 2026. Use IAB Europe’s current supporting resources when checking an implementation. These resources also list the current policy documents. Technical release numbers and policy version numbers are different, so a newer policy number does not mean your integration should be labelled “TCF v5”.

How the choices travel

A visitor sees information about purposes and vendors, then makes a choice through the consent interface. The resulting TC string communicates relevant information to participating vendors.

That string is one part of the evidence. It needs to match what the person saw, the available choices and the actual vendor configuration. Partners must also interpret and respect it correctly.

A long encoded string can look reassuring without proving much on its own. Test the human experience and the downstream behaviour together. This is especially important when the vendor list changes or a new advertising partner starts receiving data.

Five things to get right

1. Start with the partners you actually use

List the advertising partners involved in your website and how each receives data. Identify which require TCF and which operate outside it.

Keep the disclosed list aligned with the real implementation. A list containing hundreds of unused vendors makes the experience harder to understand and the configuration harder to maintain. Conversely, leaving an active recipient out creates a transparency problem.

2. Explain purposes in a way visitors can use

People should be able to understand the choices without knowing advertising terminology. Use the framework’s required information and presentation rules while keeping surrounding explanations clear.

Separate optional purposes appropriately. Do not make “accept” the only practical route through the interface. Check how the first layer leads to purpose and vendor details, especially on mobile.

3. Check the permissions behind each vendor

The framework supports different signals, including consent and information relevant to legitimate interests. A vendor declaration does not establish that your particular processing is necessary, proportionate or lawful.

Apply the relevant legal assessment to your actual activities. The EDPB’s guidance on lawful processing explains why selecting a lawful basis requires more than choosing a setting. Cookie consent requirements also remain a separate consideration.

4. Validate the v2.3 signal and lifecycle

Check that the implementation generates the required Disclosed Vendors information and that it matches the interface. Test before a choice, after acceptance, after rejection and after a later change.

The official TCF implementation guidelines describe technical behaviour. Use them to verify when partners receive updates and how the integration handles an unavailable or unresolved consent state.

Do not treat missing information as permission. Check what happens if the consent interface loads slowly, a script fails or a vendor requests a signal before the user has chosen.

5. Keep changes understandable and traceable

A new purpose or materially different vendor setup may require updated information and a fresh choice. Review changes before deploying them, rather than assuming yesterday’s signal covers tomorrow’s activity.

Keep records of the interface version and relevant configuration. These help explain what visitors were told at the time, alongside the stored choice. Define a simple review routine for vendor additions, removals and policy updates.

What this means for advertising performance

Incorrect or missing signals can affect whether advertising partners process data or participate in a transaction. But a revenue or delivery change does not automatically prove that the consent interface is responsible.

For example, a publisher adding a new advertising partner should check disclosure, signal support and actual requests before comparing revenue. Also consider demand, traffic quality, placement changes and seasonal effects.

For advertisers, focus on whether the partners in your measurement and media chain require TCF. Do not assume a publisher’s consent arrangement automatically covers every use of data in your own systems.

Implementation checklist

• Check relevance: identify the partners and activities that require TCF.
• Check version: confirm v2.3 support and the current applicable policies.
• Check vendors: reconcile the displayed list with actual recipients.
• Test disclosure: verify the Disclosed Vendors segment matches what was shown.
• Test choices: acceptance, rejection, purpose selection and later withdrawal.
• Test timing: inspect behaviour before a valid choice is available.
• Check other tools: cover vendors that do not participate in TCF separately.
• Review changes: reassess new partners, purposes and interface updates.

FAQ