A TC String is a compact, base64-encoded record of a user's IAB TCF consent choices. A CMP writes it the moment a visitor sets their cookie preferences. It packs purpose, vendor, and publisher signals into fixed bit fields, then encodes the result.
Every ad-tech vendor that later touches the page reads that same string to know what it is allowed to do.
How Does the TC String Work? (The Short Answer)
A CMP collects a user's consent and objection choices. It packs them into fixed-width bit fields, then base64-encodes the result into one portable string. Vendors decode that string to check their own permissions.
The string is not a message or a log entry. It is structured data, and every position in it means something specific. Bit 4 of the Purposes field is always "personalized ad selection," regardless of which CMP wrote the string or which site it came from.
That fixed structure lets hundreds of independent ad-tech vendors read the same bits and agree on what they mean. None of them wrote the string themselves. The sections below walk through what the string contains, how a CMP builds it, and how a vendor reads it back.
What the TC String Encodes: Consent as Data, Not Text
The TC String encodes machine-readable consent and metadata, not readable sentences. A decoder is required to see what any given string actually says.
It carries:
- Purpose consent: which of the 11 defined data-processing purposes the user allowed
- Purpose legitimate interest: which purposes the CMP is relying on legitimate interest for, where LI is a permitted legal basis
- Special feature opt-ins: whether the user allowed features like precise geolocation
- Per-vendor consent: which individual vendors, identified by their Global Vendor List (GVL) Vendor ID, the user allowed
- Per-vendor legitimate interest: the same, for the legitimate-interest legal basis
- Publisher restrictions: limits the publisher itself places on top of vendor defaults
- Metadata: string version, creation and update timestamps, CMP ID, GVL version, and TCF policy version
One Reddit thread captures the practical effect of this design well. An ad-ops practitioner in r/adops asked whether the consent string mattered given how many vendors a page runs. The answer was direct: "every consent string we receive contains the consent for hundreds of vendors." One compact string, not one record per vendor.
How a CMP Builds and Encodes the TC String: Step by Step
A CMP builds a TC String in four stages. It collects the user's choices, packs them into bit fields, base64-encodes the fields into a string, then stamps and stores the result.
Step 1: The CMP Collects the User's Choices
The banner or preference center presents purposes, special features, and vendors, and records what the user allows or denies for each. These per-item decisions are the raw input to every later stage.
A registered CMP, using its assigned CMP ID, is the only entity permitted to create a valid TC String under the IAB Tech Lab specification.
Step 2: The Choices Are Packed Into Bit Fields
Each choice becomes one bit in a fixed-width, big-endian field. The Purposes field reserves 24 bits, one per possible Purpose ID, even though TCF v2.3 currently defines only 11.
Vendor consent uses whichever encoding produces the smaller output. A BitField sets one bit per vendor up to the highest Vendor ID (MaxVendorId); a Range lists vendor ID intervals instead. The same underlying consent can therefore encode two different ways depending on which vendors are involved.
Step 3: The Bit Fields Are Base64-Encoded Into the String
The concatenated bit fields are converted into a URL-safe base64 string, the alphanumeric text that eventually travels in a cookie or an ad request. This is the step that turns structured bits into the single string every vendor recognizes.
Step 4: The String Is Stored and Version-Stamped
The CMP stamps the string with a Version number and Created/LastUpdated timestamps, recorded in deciseconds since epoch at day-level precision. It adds its CmpId, the GVL version it used, and the current TCF policy version, then stores the result, typically in the euconsent-v2 browser cookie.
Inside the TC String: The Three Segments
A TC String has three possible segments joined by a dot character, with the Core String always first: Core String, Disclosed Vendors, and Publisher TC.
A correction belongs here. Some sources, including Google's own AI Overview for this query, still describe a four-segment structure with a separate "Out-of-Band" or Global Scope signal. That framing is outdated: the IAB Tech Lab deprecated Out-of-Band signaling and the Global Scope string, making both invalid, on 1 September 2021. The current TC String, including every v2.3 string, has three segments.
The Core String (Always First, Always Required)
The Core String is the mandatory block every vendor must evaluate. It carries the main consent and legitimate-interest signals, the metadata from Step 4 above, and the vendor consent bitfield or range.
The Disclosed Vendors Segment (Mandatory Since TCF v2.3)
The Disclosed Vendors segment records which vendors the CMP actually disclosed to the user in its interface, distinct from which vendors the user consented to. TCF v2.3 made this segment mandatory to close a gap. Without it, a vendor relying on legitimate interest for a Special Purpose had no reliable signal of whether it was disclosed at all.
IAB Europe set the enforcement date precisely. TC strings created before 28 February 2026 without a Disclosed Vendors segment remain valid after that date. Any TC string created on or after 1 March 2026 without the segment is invalid.
The Publisher TC Segment (Optional)
The Publisher TC segment carries the publisher's own purpose consent and legitimate-interest signals, plus any custom publisher-defined purposes. It is optional. It follows the Core String, and because it carries its own Segment ID, it can appear in any order relative to the Disclosed Vendors segment.
What the Core String Actually Contains
The Core String's field set is where the string's real information density lives.
| Field | What it means |
|---|---|
| Version | The TC String format version |
| Created / LastUpdated | Deciseconds since epoch, day-level precision |
| CmpId | The registered CMP that wrote the string |
| CmpVersion | The CMP's own internal version number |
| ConsentScreen | An internal CMP screen identifier |
| ConsentLanguage | The two-letter language the banner displayed in |
| VendorListVersion | The GVL version the CMP used to build the string |
| TcfPolicyVersion | The TCF policy version in force (currently 5) |
| IsServiceSpecific | Whether the string applies to one service or is shared across a domain group |
| PurposesConsent | 24-bit field, one bit per Purpose ID, consent state |
| PurposesLITransparency | 24-bit field, legitimate-interest transparency per Purpose |
| SpecialFeatureOptIns | 12-bit field, one bit per Special Feature |
| PublisherCC | The publisher's country code |
| Vendor Consent (MaxVendorId + BitField/Range) | Per-vendor consent, encoded as whichever format is smaller |
Every field here is drawn from the IAB Tech Lab's published consent-string specification.
Fields are stored in big-endian format. Bit numberings are left-to-right.
How Vendors Read and Decode the TC String
A vendor retrieves the TC String through the CMP's __tcfapi JavaScript function, an ad or bid request, or the gdpr_consent URL macro. It then base64-decodes the string before checking its own permissions.
Once decoded, the vendor looks up its own Vendor ID in the vendor consent section. It then checks whether its required Purposes are consented or covered by legitimate interest, and checks for any Publisher Restrictions that override its defaults. Only after all three checks pass does it process the user's data for that purpose.
Google's own publisher integration documentation states the division of labor plainly.
The CMP creates and sends the Transparency and Consent (TC) string. Then, Google's ad tags and SDKs consume the TC string they receive from the CMP.
Vendors read; they never write or modify the string. The IAB Tech Lab specification is explicit that TC strings must always be propagated as is, not modified.
Where the TC String Lives: Cookie, API, and Ad Request
A TC String lives in three places at once: a browser cookie, a JavaScript API response, and the payload of outbound ad requests.
- The
euconsent-v2cookie stores the string in the browser, set by the CMP after the user makes a choice - The
__tcfapi()function returns the current string on demand to any script that calls it - Outbound ad and bid requests carry the string, either as an OpenRTB field or via the
gdpr_consentURL macro, so it reaches SSPs and DSPs downstream
An adops thread in r/adops on unified consent describes this distribution path directly.
The TC string (containing consent, purposes, and involved vendors) is not passed via API to the participants but through ad requests.
In-app, Android implementations store the equivalent signal in IABTCF_* SharedPreferences keys instead of a cookie. Ad SDKs read it the same way.
A Real TC String, Decoded
Decoding a real TC String turns the abstract bit-packing above into visible fields. The example string CPokAsAPokAsABEACBENC7CgAP_AAH_AAAwIAAAAAAAA, decoded through UniConsent's TCF decoder, produces the following Core String values.
| Field | Decoded value |
|---|---|
| Version | 2 |
| Created | March 13, 2023, 06:00:00 GMT+0600 |
| Last Updated | March 13, 2023, 06:00:00 GMT+0600 |
| CmpId | 68 |
| CmpVersion | 2 |
| ConsentScreen | 1 |
| ConsentLanguage | EN |
| VendorListVersion | 187 |
| TcfPolicyVersion | 2 |
| IsServiceSpecific | true |
| PurposesConsent | 10 of the Purposes flagged true, including Purpose 10 (develop and improve services) |
This particular string predates TCF v2.3. Its TcfPolicyVersion is 2 and it carries no Disclosed Vendors segment, consistent with its March 2023 timestamp. That is a useful contrast: it remains valid as a Core-only string only because it was created before the 28 February 2026 cutoff. A string built today without a Disclosed Vendors segment would be rejected.
What Makes a TC String Valid (and When It Expires)
A TC String stops being valid under two independent rules: it ages past its consent-renewal window, or it lacks a segment the current policy requires.
The two rules answer different questions and should not be conflated:
- Consent renewal: TCF policy requires re-obtaining consent at least every 13 months. A string older than 13 months is invalid, and Google stops serving ads against it, surfacing as AdSense error 3.3 (stale consent) or 7.8 (invalid string).
- Segment completeness: a TC string created on or after 1 March 2026 without a Disclosed Vendors segment is invalid, per the TCF v2.3 transition rules above. Strings created before that date keep working even without the segment.
A Reddit user in r/adops quoting IAB policy directly summarized the renewal rule.
If the consent decision is more than 13 months old, the TC string will no longer be considered valid and Google will not serve ads to that user.
Common Misconceptions About the TC String
Four assumptions about the TC String are wrong often enough to correct directly.
- The TC String has four segments, including Out-of-Band signaling. Outdated. Out-of-Band and the Global Scope string were deprecated and made invalid on 1 September 2021. The current structure, including every v2.3 string, has three segments: Core String, Disclosed Vendors, and Publisher TC.
- Each vendor's consent is stored as a separate cookie or record. No. One compact bitfield or range encodes consent for every vendor, often hundreds, inside the single string.
- The TC String is human-readable. No. It is base64-encoded bit data. Reading it requires a decoder like UniConsent's or the IAB GPP tool.
- A TC String never expires. No. Consent must be renewed within 13 months, and a string created after 1 March 2026 without a Disclosed Vendors segment is invalid regardless of age.
FAQs
Is the TC String human-readable?
No. It is a base64-encoded bit-packed string. Reading its actual field values requires pasting it into a decoder such as UniConsent's TCF decoder or iabgpp.com.
How many segments does the TC String have?
Three: Core String, Disclosed Vendors, and Publisher TC. The older four-segment framing that includes Out-of-Band signaling is deprecated and no longer accurate.
How long is a TC string valid?
Consent must be renewed at least every 13 months, or the string becomes invalid. Separately, a string created on or after 1 March 2026 without a Disclosed Vendors segment is invalid regardless of age.
What is the difference between purpose consent and vendor consent in the TC String?
Purpose consent records which data-processing purposes the user allowed. Vendor consent records which specific vendors the user allowed. A vendor needs both a consented purpose and its own vendor consent bit set before it can process data for that purpose.
Can I decode a TC String myself?
Yes. Paste the string into a public decoder, such as UniConsent's TCF decoder or the IAB GPP tool at iabgpp.com, to see every field's value.
Does the TC String contain personal data?
No. It encodes consent choices, purpose and vendor IDs, and metadata like timestamps and CMP ID. It does not contain names, emails, or other directly identifying information.
What cookie stores the TC String?
The euconsent-v2 cookie stores it in the browser. In-app implementations store the equivalent signal in IABTCF_* SharedPreferences keys instead of a cookie.
Is the TC String the same as Google Consent Mode signals?
No. The TC String is the IAB TCF's own consent record read by TCF-registered vendors. Google Consent Mode is a separate Google-specific signaling mechanism for Analytics and Ads.
What changed in the TC String for TCF v2.3?
The Disclosed Vendors segment became mandatory. TC strings created before 28 February 2026 without it remain valid. Any string created on or after 1 March 2026 without that segment is invalid.
Understanding how the string is built and read is the mechanism half of working with the IAB TCF. For the framework itself, see what the IAB TCF is and how the IAB TCF works end to end. Each consented purpose maps to one bit, detailed further in TCF purposes and special purposes, and vendors are identified against the Global Vendor List. Consently is a TCF registered CMP that generates a valid, current-version TC String automatically, with no manual encoding required. See Consently's IAB TCF support for how it fits into a live setup.
