Blog · TCF v2.3
TCF v2.3 made disclosedVendors mandatory. A v2.2 string after March 1 is invalid on new consents.
IAB Europe released TCF v2.3 on 19 June 2025. After 28 February 2026, new TC strings without disclosedVendors are invalid. Old strings stay until the user renews.
That is a wire change, not a new cookie banner. The previously optional disclosedVendors segment is now mandatory so vendors can tell whether they were shown in the CMP UI. tcfPolicyVersion stays 5. A decoder that keys off policy version 6 will never see this release. The segment presence is how you know the string was created under 2.3.
Monday 2 March 2026 is the first business day after the cut. CMPs that still mint core-only strings on new consents are minting invalid TC strings. Vendors that still ignore the segment are reading an incomplete legal-basis story. Google Consent Mode is a different pipe. Do not wait for a Consent Mode flag to tell you the TC string grew a segment.
The ambiguity v2.2 could not close
IAB Europe's transition note is about Special Purposes under Legitimate Interest. Under v2.2, a vendor that declares both Special Purpose(s) and Purpose(s) under LI could not tell two different zeros apart. If the Vendor Legitimate Interest bit for that vendor is 0, the vendor does not know whether it was never disclosed in the CMP UI, or whether the user exercised the right to object. Special Purposes cannot be objected to inside the Framework. The vendor still needs to know if transparency was established.
A 2021 notification already solved the case for vendors that only declare Special Purposes. It did not solve the mixed declaration. v2.3 makes disclosedVendors mandatory so the vendor can always check a dedicated bit: 1 means disclosed, 0 means not disclosed. Vendors that only declare Special Purposes must also use that segment to decide whether the CMP established transparency, instead of reading the LI bit in the Vendor Legitimate Interest section.
IAB Tech Lab's public-comment writeup is the same mechanism in engineer English. The Disclosed Vendors segment already existed. It was optional and intended for CMPs, not for the string shared with vendors. v2.3 requires it in all TC strings, after the Core segment. The string may also include an optional Publisher Purposes Transparency and Consent segment.
What changes on 1 March, and what does not
IAB Europe's 15 December 2025 explainer and the 19 August 2025 participant letter agree on the dates. The transition period concludes on 28 February 2026. Starting 1 March 2026, any TC string created without the disclosedVendors segment is invalid. Strings created before 1 March 2026 without the segment remain valid until they are replaced as users renew or change choices. CMPs must not be required to re-surface the UI to accommodate this change.
If a CMP already used disclosedVendors, or kept a record of which vendors were disclosed when the string was created, it may update existing strings by inserting the segment. lastUpdated must not be changed in that case. If the CMP did not keep that record, it should wait for the user to renew. Guessing the disclosed set after the fact is not the documented path.
Publishers on a commercial CMP should not feel a resurfacing project. Publishers running a private CMP have to follow the corresponding guidance themselves. The TCF overview page also dates v2.3 as launched in April 2025. That is the public-comment window. The transition article's release date for the version you have to mint is 19 June 2025, with iabtcf-es updated to the 2.3 specs. Use the June date for implementation, not the April announcement.
The string shape, and the field that does not bump
The Core String still comes first. disclosedVendors and PublisherTC follow. Both of those segments carry unique Segment IDs, so they may appear in either order after Core. A parser that assumes [Core].[disclosedVendors].[PublisherTC] and rejects the reverse order is inventing a rule IAB Europe explicitly walked back.
tcfPolicyVersion remains 5. IAB Europe said so in the August letter: this is solely a change of the Technical Specifications. The inclusion of the disclosedVendors segment is how you determine whether the string was created under 2.3. If your CMP, SSR, or ad-request logger stores policy version as the TCF version, you will classify valid 2.3 strings as 2.2 until you inspect segments.
Until 28 February 2026, CMPs must continue to set the Legitimate Interest bit to 1 for vendors registered for Special Purposes only that were disclosed on the CMP. That is so vendors who have not yet shipped 2.3 still see the pre-enforcement signal. After the date, vendors affected by the ambiguity must recognise and act on disclosedVendors. Any vendor surfaced by the CMP must be in the segment when the segment is present.
The string a v2.2 CMP will still mint
Policy version 5 with a core-only string. After 28 February 2026 that shape is invalid on a newly created consent.
{
"tcString": "<core-only TC string, no disclosedVendors segment>",
"tcfPolicyVersion": 5,
"cmpId": 123,
"gdprApplies": true
}
A pixel or bid request that only logs tcfPolicyVersion will look fine. The hop that needs the segment is the vendor that declares Special Purposes under LI and needs to know it was disclosed. If the CMP never adds the segment, that vendor cannot close the ambiguity. If a vendor decoder never reads the segment, a perfectly valid 2.3 string is still an unread signal.
Consent Mode is not this segment. ad_storage, analytics_storage, ad_user_data, and ad_personalization ride on the Google tag. The TC string is the TCF artifact on the CMP API and on whatever you forward to vendors. You can have a granted Consent Mode update and an invalid TC string on the same page load. You can have a valid 2.3 string and still be missing Consent Mode pings. Lint both. Do not collapse them into one banner QA ticket.
Names that do not translate
- TCF v2.3 is not tcfPolicyVersion 6. Policy version stays 5.
- disclosedVendors was optional under 2.2. It is mandatory on strings created after 28 February 2026.
- A 0 in Vendor Legitimate Interest is not the same as a 0 in disclosedVendors.
- Special Purposes cannot be objected to in the Framework. The disclosed bit is how transparency is proven.
- lastUpdated must not change when a CMP backfills disclosedVendors onto an existing string.
- Google Consent Mode is not the TC string. Do not treat a Consent Mode ping as TCF v2.3 support.
What vendors and CMPs actually do with the bit
Vendors can start honouring disclosedVendors as soon as they receive strings that include it. After 28 February 2026 they must. The check is the bit for their Vendor ID in that segment. Process Special Purposes only when disclosed is 1, subject to the rest of the TCF policies. Do not invent a Google Ads error code on top of that unless you have a Google primary in hand. Agency recaps of Limited Ads and error 1.4 are a different story from IAB's segment mandate.
CMPs need live installs that emit the segment on every new string. No forced re-prompt. Update iabtcf-es or the equivalent encoder. Encode every vendor you surfaced. If you cannot reconstruct the disclosed set for an old string, wait for renewal. Publishers should ask their CMP for a 2.3 string dump from a fresh consent after 1 March, not a cached string from January.
QA the artifact, not the banner screenshot. Decode the TC string. Confirm a disclosedVendors segment after Core. Confirm your Vendor ID bit. Confirm policy version is still 5. If the page also runs Google tags, check Consent Mode separately. The two failures look similar in a privacy ticket and they are not the same bytes on the wire.
The tcfPolicyVersion will remain version 5 for TCF 2.3 since this is solely a change of the Technical Specifications. The inclusion of the disclosedVendor segment should be used to determine whether the TC String was created under 2.3.
IAB Europe TCF 2.3 transition letter, 19 August 2025
What to do
If you operate a CMP, ship disclosedVendors on every new TC string. Do not re-surface the UI for this change. If you kept the disclosed set, you may backfill old strings without touching lastUpdated. If you did not, wait for renewal. Keep setting the LI bit for Special Purpose-only disclosed vendors through the transition.
If you are a vendor, decode disclosedVendors and act on your bit. Do not wait for a policy-version bump that will not come. If you are a publisher, ask the CMP for a post-cut string from a new consent and decode it. Google Consent Mode stays on the tag. The TCF docs page is the contract surface for how strings show up on pixels.
This post is the market fact: after 28 February 2026, a newly created TC string without disclosedVendors is invalid. Pixellint is not affiliated with IAB Europe or IAB Tech Lab. Passing a linter means the artifact matches a published envelope. It does not mean a DPA would treat the consent as lawful, and it does not detect fraud.
Checklist
- Treat 28 February 2026 as the last day a new core-only string can be valid.
- On strings created from 1 March 2026, require a disclosedVendors segment after Core.
- Leave tcfPolicyVersion at 5. Detect 2.3 by the segment, not by a new policy number.
- Do not force a CMP UI re-prompt for this change.
- Vendors: read your disclosedVendors bit. Do not infer disclosure from a 0 LI bit.
- Keep Consent Mode checks on the Google tag. They are not a substitute for the TC string.
Sources
Contract pages
The dated argument is above. These pages are the field lists.