TCF 2.3 Disclosed Vendors Segment: What It Contains and How to Read It From a TC String
Contents
A TC string consists of segments separated by dots. The first is the core segment and carries the purposes, the legal bases and the vendors for which consent exists. The third is optional. The second – disclosed vendors – was allowed to be absent up to TCF 2.2 and has been required since 2.3.
The difference sounds like bookkeeping, and it is. That is precisely why it works: without this segment there is no way to demonstrate that a vendor which received consent was ever shown to the person giving it.
What the segment contains
Every segment after the core segment begins with three bits of segment type. The value 1 means disclosed vendors, the value 3 the publisher segment, the value 0 stands for the core segment. Sixteen bits for the highest vendor ID included follow, and then a single bit deciding how the set itself is encoded.
Layout of the "disclosed vendors" segment
SegmentType 3 bits value 1
MaxVendorId 16 bits highest vendor ID included
IsRangeEncoding 1 bit 0 = bit field, 1 = ranges
at 0 bit field MaxVendorId bits, one per vendor,
1 = shown, 0 = not shown
at 1 NumEntries 12 bits
per entry IsARange 1 bit
StartOrOnlyVendorId 16 bits
EndVendorId 16 bits, only if IsARange = 1
segment types 0 = core 1 = disclosed vendors 3 = publisher TCBoth forms describe the same set. The specification merely requires choosing the one that produces the smaller output for the given set. A contiguous selection made of a few blocks fares much better with ranges; a selection scattered across the whole list tips the arithmetic towards the bit field, because every single value costs seventeen bits there and only one in the field.
What the segment is aimed at
The gap it closes has a name: vendors appearing in the signal without ever having appeared in the interface. A consent banner could show a handful of names while the string it produced recorded consent for a considerably larger number of vendors. To whoever received the string the two cases were indistinguishable, because the information about what had been shown was simply not in it.
That is exactly the charge levelled at the framework in European proceedings, and the answer to it is unusually direct. Instead of a rule of conduct there is now a mandatory field in the data format. A party that does not disclose can no longer claim to have done so, because the field would stay empty and validation sees it.
What has been happening since the end of February
TCF 2.3 was published on 19 June 2025 and the transition ran until the end of February 2026. Google has required version 2.3 for all newly generated TC strings since 28 February 2026; the framework’s own binding deadline fell on 1 March. Validation went live in early March, and reports agree that the error report has carried a dedicated code since then for requests in which the segment is missing, malformed, or does not include Google.
The consequence is not a warning in an interface but a decision at ad delivery: the request is served limited ads or dropped. That hits a site’s revenue directly and silently, because a dropped request leaves no message in the consent tool.
Where the fault actually sits
What stands out about this change is how little it has to do with the site it affects. The string is written by the consent solution, and whether version 2.3 is produced depends on that solution’s version and configuration. A site can leave its banner untouched, meet every deadline, set every option correctly – and still emit invalid strings, because the embedded solution is still writing 2.2.
The reverse holds as well: a current solution produces the segment by itself. The effort lies in establishing which of the two cases applies, and that can be read off a single string.
How to read it off a string
The quickest route runs through the dots. A string without a dot consists of the core segment alone and therefore cannot contain the disclosure. A string with at least one dot has further segments, and the first three bits of each name its type. If the value 1 appears nowhere, the disclosure is missing too – the additional segment present is then the publisher segment.
Where a decoder is at hand the matter takes a minute: take the string from the banner or from the network panel, split it, read the segment types. Where none is at hand, counting the dots is enough for a first suspicion. If the count stays at zero the finding is unambiguous, and the question is addressed not to the site but to the vendor of the consent solution.
Related articles
2 comments
The length competition between bit field and ranges matters beyond tidiness – some RTB integrations still pass the TC string as a query parameter with a practical length ceiling. For an account with a large, scattered vendor list, is there a point where even the shorter of the two encodings pushes a string past what a given exchange accepts, or does the mandatory segment stay small enough in practice?
It can matter, yes, precisely because the segment is now mandatory rather than optional – a string that used to omit it entirely got shorter for free, and that option is gone. Whether it turns into a real ceiling problem depends on how scattered the vendor list is: a few hundred contiguous IDs cost almost nothing in ranges, while a similarly sized but scattered list can run to several hundred bits in the bit field, since a scattered selection is exactly the case where ranges lose the length competition. An account with an unusually long vendor list is worth measuring rather than assuming – decode one string and check its bit length against whatever ceiling the exchange documents.