Chapter navigation
TC String bit-level breakdown
consentRole & classification
Maintained by the Interactive Advertising Bureau (IAB) Europe, the Transparency & Consent Framework (TCF) EU v2 TC String = Core String . Disclosed Vendors . Publisher TC, three segments separated by . and each self-identified by a 3-bit SegmentType (the Core segment has no prefix). It is both the payload of Global Privacy Platform (GPP) §2 and, as a leading-C standalone string, coexists with GPP. Bit-level layout of the 17 Core fields.
- GPP section
- §2 (tcfeuv2)
- Status
- Final v2.2 (+2.3/2.4)
- Standalone
- leading C, coexists with §2
- Core fields
- 17 (last variable)
String & field layout
IAB Europe TCF v2 (policy version 4 since TCF 2.2; strings with policy < 4 invalid after 2023-09-30)
[Core String].[Disclosed Vendors].[Publisher TC] — segments after the core are "."-separated and self-identified by a 3-bit SegmentTypeSegments
Basic vendor transparency & consent; always first, no SegmentType prefix.
Vendors disclosed to the user by the CMP. Mandatory since TCF 2.3 (Apr 2025) to resolve special-purpose LI ambiguity.
Publisher's own purposes transparency & consent, incl. custom purposes.
Core String field layout
The bit ranges are the cumulative widths from the table above — the very same source as stage four of the walkthrough; the last row is the variable-length trio whose width is decided by the data itself.
| Field | Bits | Bit range | Description |
|---|---|---|---|
| Version | 6 | bits[0..6) | Encoding format version (2). |
| Created | 36 | bits[6..42) | Epoch deciseconds when the TC string was first created. |
| LastUpdated | 36 | bits[42..78) | Epoch deciseconds of the last update (since Dec 2021 kept equal to Created at day-level resolution). |
| CmpId | 12 | bits[78..90) | ID of the CMP that last updated the string. |
| CmpVersion | 12 | bits[90..102) | Version of that CMP. |
| ConsentScreen | 6 | bits[102..108) | CMP screen number where consent was given. |
| ConsentLanguage | 12 | bits[108..120) | ISO 639-1 language of the CMP UI (2×6 bits, a=0…z=25). |
| VendorListVersion | 12 | bits[120..132) | Global Vendor List version used. |
| TcfPolicyVersion | 6 | bits[132..138) | TCF policy version of the GVL (4 since TCF 2.2). |
| IsServiceSpecific | 1 | bits[138..139) | Must be 1; a string with 0 is considered invalid by vendors. |
| UseNonStandardTexts | 1 | bits[139..140) | CMP modified standard stack/illustration texts. |
| SpecialFeatureOptIns | 12 | bits[140..152) | Opt-in per Special Feature (1–2). |
| PurposesConsent | 24 | bits[152..176) | Consent per Purpose 1–24 (legal basis: consent). |
| PurposesLITransparency | 24 | bits[176..200) | Legitimate interest per Purpose; TCF 2.2 deprecated LI for purposes 3–6 (bits must be 0). |
| PurposeOneTreatment | 1 | bits[200..201) | 1 = Purpose 1 not disclosed (special treatment by jurisdiction). |
| PublisherCC | 12 | bits[201..213) | ISO 3166-1 alpha-2 country determining the legislation of reference. |
| VendorConsents + VendorLI + PubRestrictions | variable | bits[213..) | Vendor Consent Section and Vendor Legitimate Interest Section (MaxVendorId int(16) + bitfield or range), then NumPubRestrictions int(12) with optional restriction entries (PurposeId 6 + RestrictionType 2 + vendor range). |
Walk through: how a real string gets decoded
Fibonacci coding and bitfields stay abstract until you watch a real string being read bit by bit. Below, an official sample is walked through in four stages: each step highlights the base64 characters and the bit range the current field covers, and shows the value read.
Sample · official GPP String Example 2DBACNY~CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA~1YNN
Full sample string
DBACNY~CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA~1YNNSegment being read
DBACNY~CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA~1YNN- Encoding
- modified base64
- Bit range
- Character-level split; this step reads no bits
- Char range
- chars[0..6)
Header
Value read
DBACNY
The whole string is split by ~ into 3 parts: the first is the Header, and every remaining part is one section's payload. The Header declares section IDs [2, 6] for this transaction.
Ordered list of Section IDs contained in the string; IDs appear in the same order as their sections. Fibonacci range: int(12) amount, then per item a single/group bit + Fibonacci offset (from last seen ID, 0-based for the first entry), groups add a Fibonacci length.
Step 1 of 29: Header, modified base64, value DBACNY
Try your own string
The walkthrough uses a fixed official sample. Replace the input below with a string captured from production to see the full field-level result, including the variable-length Vendor sections the walkthrough does not cover. All parsing happens locally in your browser; strings are never uploaded.
GPP Header
GPP v1Sections declared by the header: [2, 6]
Section 2 · EU TCF v2
tcfeuv2Core String
TCF v2Section 6 · USPrivacy String (Unencoded)
uspv1Carriage & access
- GPP §2 — Carried as one section payload inside the GPP container, apiPrefix tcfeuv2, travelling with the whole string via regs.gpp / ${GPP_STRING}.
- 独立 TC String — A leading C, no GPP container; the European Economic Area (EEA) spec states it must keep travelling in transaction headers until IAB Europe formally deprecates it — coexisting with §2, not superseded.
- __tcfapi — Read in the browser via the Consent Management Platform (CMP) JS API; see the CMP JS API chapter.
Version deltas
The TC String encoding format version is always 2 (the leading Version field of the Core segment); the TCF policy-version evolution (v2.0→v2.1→v2.2→v2.3) is covered in the version-deltas chapter. TCF version deltas →
Invalid forms
- IsServiceSpecific=0: vendors treat the string as invalid (it must be 1)
- Strings with TcfPolicyVersion<4 are invalid since 2023-09-30
- Segments after the Core lack the 3-bit SegmentType self-identification prefix