Understanding IAB TCF Consent Strings: A Complete Guide

GDPR and the Need for Consent Management

The European Union's General Data Protection Regulation (GDPR), which took effect in May 2018, fundamentally changed how digital advertising handles user data. Under GDPR, processing personal data requires a lawful basis — and for most advertising activities, that basis is the user's informed, specific, and freely given consent. This means that before an ad tech vendor can set a cookie, read a device identifier, or process data for audience targeting, the vendor must have evidence that the user agreed to that specific processing purpose.

The challenge for the ad tech ecosystem is scale. A single web page might involve dozens of vendors — the publisher's ad server, multiple demand-side platforms, data management platforms, verification services, and analytics providers — each needing consent for one or more data processing purposes. Without a standardized mechanism, each vendor would need to implement its own consent collection, creating an impossible user experience (dozens of separate consent dialogs) and an unenforceable compliance landscape.

This is the problem that the IAB Transparency and Consent Framework solves. It provides a single, standardized protocol for collecting consent, encoding it into a compact string, and distributing it across the advertising supply chain so that every vendor can read the user's choices without independent consent collection.

What Is the IAB TCF?

The IAB Transparency and Consent Framework (TCF) is a cross-industry standard, created by IAB Europe, that defines how consent is collected from users and communicated to vendors throughout the programmatic advertising chain. The framework has three main components: the Consent Management Platform (CMP) that presents the consent dialog to users, the Global Vendor List (GVL) that catalogs registered vendors and their declared processing purposes, and the TC String (consent string) that encodes the user's choices in a compact, machine-readable format.

When a user visits a website with a TCF-compliant CMP, the CMP displays a consent dialog listing the purposes for which data will be processed (such as storing information on a device, creating a personalized ads profile, or measuring content performance) and the vendors that will process data for those purposes. The user can grant or deny consent per purpose and, in some implementations, per vendor. The CMP then encodes these choices into a TC String and makes it available to all vendors on the page through a standardized JavaScript API (__tcfapi).

How Consent Strings Encode User Choices

A TCF consent string is a Base64URL-encoded binary string that packs a dense set of bit fields into a compact format suitable for transmission in cookies, URL parameters, and HTTP headers. The string uses a binary encoding where individual bits represent boolean consent signals — a 1 means consent was given, and a 0 means it was not. This bit-level encoding allows the string to represent consent decisions for hundreds of vendors and multiple purposes in a few hundred characters.

The encoding is not human-readable by design. Decoding the string requires parsing the binary structure according to the TCF specification, which defines the exact position, length, and meaning of each field. This is why a dedicated decoder tool is essential for debugging — manually interpreting a consent string by reading its Base64URL representation is impractical.

TCF String Structure

A TCF v2 consent string consists of several sections, each encoding a different aspect of the user's consent. Understanding these sections is critical for diagnosing consent-related issues in ad delivery.

Core Metadata

The first section of the string contains core metadata: the TCF version number, the date the string was created, the date it was last updated, the CMP ID (a unique identifier for the consent management platform that generated the string), the CMP version, the consent screen number (which dialog screen the user interacted with), the consent language (a two-letter ISO 639-1 code), the GVL version used when consent was collected, and the publisher country code. This metadata lets downstream systems verify that the string was generated by a registered CMP and determine which version of the vendor list was current at the time of consent.

Purpose Consent

The purpose consent section is a fixed-length bit field where each bit corresponds to one of the TCF-defined purposes. TCF v2 defines purposes such as "Store and/or access information on a device" (Purpose 1), "Select basic ads" (Purpose 2), "Create a personalized ads profile" (Purpose 3), "Select personalized ads" (Purpose 4), and "Measure ad performance" (Purpose 7), among others. A set bit indicates the user consented to that purpose; a cleared bit means they did not. Vendors check these bits to determine whether they are legally permitted to perform their declared processing activities.

Vendor Consent

The vendor consent section records which specific vendors the user has consented to. This section uses a variable-length encoding that can represent consent for hundreds of vendors efficiently. It supports two encoding modes: a bitfield (one bit per vendor up to the maximum vendor ID) and a range encoding (a compressed format that lists ranges of consented vendor IDs). The decoder automatically determines which encoding mode was used and presents the results as a list of vendor IDs with their consent status.

Legitimate Interest

In addition to consent, GDPR recognizes "legitimate interest" as an alternative lawful basis for data processing. The TCF allows vendors to declare legitimate interest for certain purposes, and the consent string includes sections that record the user's decisions regarding legitimate interest — both at the purpose level and the vendor level. A user can object to a vendor's legitimate interest claim, and this objection is recorded in the string just like a consent denial.

Publisher Segments

The publisher restrictions and publisher TC sections allow publishers to override default vendor permissions. A publisher might restrict a vendor from using consent as a legal basis for a particular purpose (requiring legitimate interest instead, or disallowing the purpose entirely). These publisher-level constraints are encoded in optional segments appended to the core string, separated by a period (.) delimiter. Not all CMPs generate publisher segments, which is important to know when debugging — a missing publisher segment is not necessarily an error.

Using the TCF String Decoder Tool

The TCF String Decoder parses TCF v2 consent strings entirely in your browser, without sending data to a server. Here is how to use it for debugging:

1. Obtain the consent string. You can extract it from the euconsent-v2 cookie in the browser's developer tools, from the __tcfapi JavaScript API on the page, or from server-side logs where the string is passed as a request parameter.
2. Paste the string into the decoder. The tool accepts the full TC String, including any segment separators (period-delimited sections).
3. Click Decode. The tool parses the binary structure and displays all fields in a human-readable format: core metadata at the top, followed by purpose consent bits, vendor consent lists, legitimate interest sections, and any publisher restrictions.
4. Review the results. Check the CMP ID against the IAB CMP registry to verify legitimacy. Verify that the expected purposes are consented. Look up specific vendor IDs to confirm their consent status. Examine the GVL version to ensure it is recent.

The Global Vendor List and Versioning

The Global Vendor List (GVL) is a JSON file maintained by IAB Europe that catalogs every vendor registered under the TCF. Each entry includes the vendor's name, ID number, declared purposes (both consent and legitimate interest), special features used, and the URL of the vendor's privacy policy. The GVL is versioned — a new version is published whenever vendors are added, removed, or modify their purpose declarations.

The GVL version recorded in a consent string indicates which vendor list was active when the CMP collected consent. This matters for debugging because vendor IDs can be reassigned if a vendor leaves the list and a new vendor takes its number in a later version. When decoding a consent string, the decoder ideally should reference the same GVL version that was used during consent collection to accurately map vendor IDs to vendor names. If the decoder uses a newer GVL version, some vendor names might not match.

Vendors are expected to re-register and update their GVL entries periodically. A stale GVL version in a consent string (one that is many months old) may indicate that the user's consent was collected long ago and has not been refreshed — which could be a compliance concern if the vendor landscape has changed significantly since then.

Common Debugging Scenarios

Missing Vendor Consent

A vendor reports that it is not receiving consent for its ID, even though the CMP dialog lists the vendor and the user clicked "Accept All." The first step is to decode the consent string and check whether the vendor's ID has a set bit in the vendor consent section. If the bit is cleared, the CMP may have a configuration error — perhaps it is using an outdated vendor list that does not include the vendor, or the vendor was accidentally excluded from the CMP's configuration. If the bit is set, the issue is downstream: the vendor's system may be reading the string incorrectly or checking the wrong section (consent vs. legitimate interest).

Stale Consent Strings

A consent string with a creation date many months in the past may not reflect the current vendor list or purpose definitions. If the GVL has been updated significantly since the string was created, some vendors that the user consented to may have changed their purpose declarations, and new vendors may not be covered at all. Best practice is to prompt users to refresh their consent periodically — many CMPs support this through configurable re-consent intervals.

Purpose Bit Errors

If a specific purpose (for example, Purpose 1 — device storage access) shows as not consented despite the user accepting the dialog, check the CMP's purpose configuration. Some CMPs allow publishers to pre-configure certain purposes as disabled or to require explicit per-purpose opt-in rather than including them in "Accept All." Also verify that publisher restrictions are not overriding the consent — the publisher segments section can restrict purposes even when the user has consented at the general level.

Verifying CMP Implementations: A 5-Step Checklist

Before launching a new CMP or updating an existing one, use this checklist to verify that it is functioning correctly:

1. Verify the CMP ID. Decode the consent string and confirm that the CMP ID matches the CMP's registration in the IAB CMP list. An unregistered or incorrect CMP ID means the string will be rejected by compliant vendors.
2. Check the GVL version. The GVL version in the string should be recent (within the last few weeks of the current GVL). An outdated version means the CMP is using a stale vendor list and may be missing new vendors or including removed ones.
3. Test "Accept All" behavior. Click "Accept All" in the CMP dialog, then decode the resulting string. All defined purposes should show consent, and all vendors in the CMP's configuration should have their bits set. If any are missing, the CMP's "Accept All" logic is incomplete.
4. Test "Reject All" behavior. Click "Reject All" and decode the string. All purpose consent bits should be cleared, and no vendors should have consent set. Some CMPs still generate a valid string with all-zero consent after rejection — this is correct behavior. The string exists to prove that the user was asked, not that they agreed.
5. Verify the __tcfapi callback. Call __tcfapi('getTCData', 2, callback) from the browser console and confirm that the response includes the expected TC String, purpose consent object, and vendor consent object. Verify that the data matches what the decoded string shows. Discrepancies indicate a bug in the CMP's API layer.

Consent String Auditing for Compliance

Regular auditing of consent strings is an essential part of privacy compliance. An audit involves collecting consent strings from production traffic, decoding them, and analyzing the results for anomalies. Look for strings with CMP IDs that do not match your registered CMP, strings with suspiciously old creation dates, strings where all purposes are consented (which could indicate a non-compliant "consent wall" that forces acceptance), and strings where the GVL version is significantly outdated.

For systematic auditing, export a sample of consent strings from your server logs, decode each one using the tool, and tabulate the results: what percentage of users have full consent vs. partial consent, which purposes are most frequently denied, which vendors are most frequently excluded, and how old the average consent string is. This data informs both compliance reporting and CMP optimization — if a purpose is frequently denied, the CMP's explanatory text for that purpose may need improvement.

Compliance teams should also verify that consent strings are being propagated correctly through the supply chain. A vendor that receives bid requests without a consent string, or with a malformed string, cannot make informed consent decisions. Spot-checking the strings that arrive at each point in the chain (publisher page, SSP, DSP) ensures that the signal is transmitted intact.