{"id":10308,"date":"2026-08-28T07:20:00","date_gmt":"2026-08-28T05:20:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10308"},"modified":"2026-10-24T03:57:10","modified_gmt":"2026-10-24T01:57:10","slug":"reading-a-tc-string-what-sits-in-the-213-header-bits","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/data-privacy\/reading-a-tc-string-what-sits-in-the-213-header-bits\/","title":{"rendered":"Reading a TC String: What Sits in the 213 Header Bits"},"content":{"rendered":"

A TC string stores transparency and consent signals in a compact format. Decoding reveals recorded values such as purpose flags, vendor choices and the referenced vendor-list version. It does not prove that the banner was correct, that a particular person gave valid consent or that a vendor respected the result.<\/p>\n

The format is encoded, not encrypted. Reading requires no secret key. The string is also not a signed audit trail. A useful inspection therefore combines decoded signals with the actual dialogue, the matching Global Vendor List (GVL) and observed requests.<\/p>\n

\"TC
Encoded signals are not a signed record of consent<\/figcaption><\/figure>\n

The fixed prefix: 213 bits, including purposes<\/h2>\n

Each segment uses the Base64url alphabet, with six bits represented by each character. Dots separate segments. The first six bits encode the format version: value 2 becomes 000010<\/code>, represented by C<\/code>. A leading C identifies this version field; it does not validate the remaining string.<\/p>\n

The core starts with the following fields in order. Bit positions below are zero-based: position 0 is the first bit. The 213-bit prefix already contains the purpose flags. Vendor data starts at position 213, the 214th bit.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Field<\/th>\nBit positions<\/th>\nLength<\/th>\n<\/tr>\n<\/thead>\n
Version<\/code><\/td>\n0\u20135<\/td>\n6<\/td>\n<\/tr>\n
Created<\/code><\/td>\n6\u201341<\/td>\n36<\/td>\n<\/tr>\n
LastUpdated<\/code><\/td>\n42\u201377<\/td>\n36<\/td>\n<\/tr>\n
CmpId<\/code><\/td>\n78\u201389<\/td>\n12<\/td>\n<\/tr>\n
CmpVersion<\/code><\/td>\n90\u2013101<\/td>\n12<\/td>\n<\/tr>\n
ConsentScreen<\/code><\/td>\n102\u2013107<\/td>\n6<\/td>\n<\/tr>\n
ConsentLanguage<\/code><\/td>\n108\u2013119<\/td>\n12<\/td>\n<\/tr>\n
VendorListVersion<\/code><\/td>\n120\u2013131<\/td>\n12<\/td>\n<\/tr>\n
TcfPolicyVersion<\/code><\/td>\n132\u2013137<\/td>\n6<\/td>\n<\/tr>\n
IsServiceSpecific<\/code><\/td>\n138\u2013138<\/td>\n1<\/td>\n<\/tr>\n
UseNonStandardTexts<\/code><\/td>\n139\u2013139<\/td>\n1<\/td>\n<\/tr>\n
SpecialFeatureOptIns<\/code><\/td>\n140\u2013151<\/td>\n12<\/td>\n<\/tr>\n
PurposesConsent<\/code><\/td>\n152\u2013175<\/td>\n24<\/td>\n<\/tr>\n
PurposesLITransparency<\/code><\/td>\n176\u2013199<\/td>\n24<\/td>\n<\/tr>\n
PurposeOneTreatment<\/code><\/td>\n200\u2013200<\/td>\n1<\/td>\n<\/tr>\n
PublisherCC<\/code><\/td>\n201\u2013212<\/td>\n12<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The prefix ends after the first three bits of the 36th Base64url character. The remaining three bits belong to vendor data. Reading only 35 characters loses information; treating all 36 characters as the prefix consumes too much.<\/p>\n

Dates and versions need separate interpretation<\/h2>\n

The timestamp fields retain 36-bit values expressed in tenths of a second since the Unix epoch. Under the current specification, however, Created<\/code> and LastUpdated<\/code> contain the same UTC day-level update timestamp. Multiplying by 100 converts the stored value to JavaScript milliseconds. The numeric unit does not establish tenth-of-a-second accuracy for the consent action.<\/p>\n

An old update date is a reason to inspect renewal and reminder handling. A recent date alone is not proof of fresh consent, and a thirteen-month comparison does not reconstruct consent history. The technical specification discusses reminders at least every thirteen months; the string is not a substitute for the underlying evidence.<\/p>\n

Format version 2, framework versions such as TCF 2.3 or 2.4, the policy version and the GVL version are different identifiers. A policy value of 4 was introduced with TCF 2.2; a value of 4 or higher is not proof that every current requirement has been implemented. VendorListVersion identifies the GVL snapshot used, not whether every vendor in that list appeared in the dialogue.<\/p>\n

Vendor sections: length is not a consent score<\/h2>\n

A vendor section begins with a 16-bit maximum vendor ID and a one-bit encoding flag. Bitfield encoding then uses one bit per ID up to that maximum. Range encoding adds a 12-bit entry count. Each entry has a one-bit range flag and a 16-bit first or sole ID; a further 16-bit last ID appears only for a range.<\/p>\n

For a maximum ID of 800, a bitfield occupies 817 bits including the section header. Fifty isolated IDs need 879 bits as ranges: 17 + 12 + 50 \u00d7 17. One contiguous range needs only 62 bits: 17 + 12 + 33. An encoder choosing the smaller representation would use the bitfield in the first example and the range in the second. Accepting everything is therefore not a universal guarantee of a short string.<\/p>\n

Vendor consent and legitimate-interest signals occupy separate sections. Publisher restrictions and further segments also affect total length. A long string does not by itself mean broad consent, corruption or a large number of selected vendors.<\/p>\n

Current rules beyond the bit layout<\/h2>\n

TCF 2.2 removed legitimate interest as an available basis for purposes 3\u20136. Purpose 1 already had consent as its permitted basis; its jurisdiction-specific PurposeOneTreatment<\/code> flag is a separate matter. Special purposes have a separate numbering space and must not be read as ordinary purpose bits.<\/p>\n

For the currently defined purposes 1\u201311, reserved positions 12\u201324 are not additional choices. Unexpected set bits deserve validation against the applicable specification and GVL. Such a finding establishes an inconsistency, not who wrote the implementation. Purpose signals alone also do not authorize every vendor: vendor signals, disclosures, declared purposes and publisher restrictions belong in the assessment.<\/p>\n

TCF 2.3 made the DisclosedVendors<\/code> segment mandatory for strings created from March 1, 2026. Earlier strings without that segment retain the transition exception; absence is therefore not automatically the same finding for every historical string. Segment type 1 records vendor disclosure, while optional type 3 describes publisher purposes. The former allowed-vendors segment, type 2, was removed in TCF 2.2.<\/p>\n

TCF 2.4 subsequently introduced updated feature disclosures. The official implementation deadline was October 23, 2026 for web environments and is February 23, 2027 for mobile apps and CTV. Those changes do not turn the six-bit encoding version into 2.4. A bit decoder cannot verify the required wording and presentation of the dialogue.<\/p>\n

\n

Questions and answers<\/h2>\n

Is euconsent-v2 required?<\/h3>\n

No. The CMP chooses the storage mechanism; a different cookie name or non-cookie storage is possible. Absence of that cookie proves neither absence nor correctness of consent management.<\/p>\n

Which browser API is appropriate?<\/h3>\n

getTCData<\/code> was deprecated in TCF 2.2. The supported approach uses addEventListener<\/code>, checks callback success and the CMP\/event state, and reads tcString<\/code> when available. The callback may initially contain incomplete data while the CMP loads. A one-time diagnostic reader should remove its listener with removeEventListener<\/code> and the returned listener ID after obtaining the intended snapshot. An application following later choice changes must retain a suitable subscription.<\/p>\n

How can incomplete data be detected?<\/h3>\n

A decoder checks the alphabet, field lengths, entry counts, ranges and segment types. Base64 decoding alone checks none of the policy rules. For byte-oriented decoders, Base64url alphabet conversion and any required padding apply separately to each segment. Direct conversion from each character to six bits avoids byte-boundary assumptions.<\/p>\n

Unexpectedly missing bits can result from copying, storage, encoding or transport errors. A length limit is one possible cause, not a diagnosis. RFC 6265 recommends that general-purpose browsers support at least 4096 bytes per cookie including name, value and attributes; the requirement is SHOULD, not MUST. Oversized cookies or request headers can be rejected rather than silently truncated. Comparison of the stored value, CMP API output and transmitted value helps locate the discrepancy.<\/p>\n

What belongs in a practical review?<\/h3>\n

A repeatable review records the chosen test action, the corresponding UI state, decoded purpose and vendor signals, relevant restrictions and the matching GVL snapshot. Network observation then checks whether processing follows the expected decision. None of those individual checks establishes comprehensive legal compliance.<\/p>\n<\/div>\n

\n

Sources<\/h2>\n