The IAB Transparency and Consent Framework (TCF) is IAB Europe's industry standard for passing a visitor's consent choices to advertising vendors in a coded TC string. Version 2.3, often searched as TCF 2.3, made one part of that string mandatory: a disclosedVendors segment that records which vendors the visitor was actually shown. The transition ended on 28 February 2026, and Google requires TCF v2.3 for every TC string generated on or after 1 March 2026.
TCF v2.3 has been mandatory since 1 March 2026
IAB Europe released TCF v2.3 on 19 June 2025, with a transition period that, according to IAB Europe's transition guide, concluded on 28 February 2026. A TC string created after that date without a disclosedVendors segment is invalid under the framework's policy.
Google enforces the change in its advertising products. Its TCF v2.3 troubleshooting page says that TCF v2.3 is mandatory for all TC strings generated on or after 1 March 2026, and it lists error 1.4 for requests where the disclosed vendors section is missing, malformed, or does not include Google (vendor ID 755).
If you monetise traffic from the EEA, UK, or Switzerland through Google Ad Manager, AdSense, or AdMob, this affects you directly.
What actually changed between TCF v2.2 and v2.3
TCF v2.2, launched in May 2023, was primarily a policy update. It removed legitimate interest as a legal basis for advertising purposes and introduced stricter requirements for consent banner design. TCF v2.3 is a technical update. The user-facing consent banner stays the same. The change happens entirely within the TC string itself.
In short, the disclosedVendors segment is now mandatory in every TC string. Previously, this segment was optional.
A TC string under v2.3 follows this structure:
[Core segment].[disclosedVendors segment].[Publisher TC]
The disclosed vendors segment is a binary record (1 = disclosed, 0 = not disclosed) indicating which vendors were actually shown to the user in the CMP interface. Each vendor ID gets a corresponding bit. If vendor ID 755 (Google) has a 1, it means the user saw Google listed in the consent dialogue. If it has a 0, Google was not displayed.
The three segments of a TCF v2.3 TC string
The "ghost vendor" problem
Under TCF v2.2, vendors could receive a consent string but had no reliable way to confirm they were actually shown to the user. Consider this scenario: a vendor declares legitimate interest for Special Purposes (such as fraud prevention or security monitoring). A user exercises their right to object to that vendor's processing. The CMP sets the legitimate interest bit for that vendor to 0.
The vendor receives the string and sees the 0, but cannot tell what it means. Did the user actively object? Or was the vendor never disclosed in the consent interface, so the user never had a chance to see it at all?
That ambiguity matters because Special Purposes still require transparency under the GDPR. A vendor processing data for fraud prevention without having been disclosed to the user risks a transparency failure, even if it has a legitimate interest basis. TCF v2.3 removes the guesswork. If the disclosed vendors bit reads 0, the vendor was not shown, and it has no basis in the framework for Special Purposes processing.
Google treats a missing disclosure as an error
Google is not merely participating in TCF v2.3. It treats the transition as a hard line: TCF v2.3 is mandatory for every TC string generated on or after 1 March 2026.
Error 1.4 sits in Google's "limited consent scenarios" alongside errors 1.1, 1.2 and 1.3, which Google says always take precedence over misconfiguration errors, even when a single request has several issues. For error 1.4, Google's description is that it "was not able to operate on this request". Misconfiguration errors, by contrast, lead Google to attempt limited ads. The full list of codes is in the guide to TCF consent string errors.
What error 1.4 means for revenue
A request Google cannot operate on does not reach Google's demand. Publishers who rely on programmatic demand from Google see the effect in fill rates and eCPMs for EEA, UK and Swiss traffic. A sudden drop since 1 March 2026 is a strong signal that something is wrong with your TC string output.
The legal backdrop: the Belgian DPA ruling and the CJEU
TCF v2.3 arrives against a background of sustained legal scrutiny of the framework itself. The Belgian Data Protection Authority (APD) fined IAB Europe EUR 250,000 in February 2022, ruling that the TCF failed to comply with GDPR requirements. IAB Europe appealed, and the Belgian Market Court referred key questions to the Court of Justice of the European Union.
In its judgment in case C-604/22 of 7 March 2024, the CJEU confirmed two critical points: the TC string qualifies as personal data under Article 4(1) GDPR when combined with identifying information such as an IP address, and IAB Europe can be considered a joint controller under Article 4(7) for the creation and use of TC strings within the framework.
On 14 May 2025, the Brussels Market Court (part of the Brussels Court of Appeal) delivered its ruling. It upheld the EUR 250,000 fine against IAB Europe, confirmed that the TC string is personal data, and agreed that IAB Europe acts as a joint controller for processing within the TCF. The Court narrowed the scope, ruling that IAB Europe is not a joint controller for downstream processing in real-time bidding (RTB) over which it has no control.
One important nuance: the ruling addressed TCF versions 1.0 and 2.0 specifically. Versions 2.2 and 2.3 were not under judicial review. Many of the criticised shortcomings were already addressed in v2.2, and v2.3 further strengthens the transparency mechanism. Whether these later versions fully satisfy GDPR requirements remains an open question for future regulatory scrutiny.
Who needs to act, and who does not
The answer depends on how you collect consent and serve ads.
| Scenario | Action required |
|---|---|
| You use a commercial CMP registered with IAB Europe for the TCF | Probably none, but verify by decoding a fresh TC string and checking for the disclosed vendors segment. |
| You use Google's own Privacy & messaging CMP | None. Google says its consent management solutions support TCF v2.3 for its European regulations messages. |
| You run a private or custom-built CMP | Update your TC string generation code to include the mandatory disclosedVendors segment after the core segment. |
| You serve ads only outside the EEA, UK, and Switzerland | None. Google's TCF requirement applies to traffic from these regions only. |
| You do not serve third-party ads at all (no AdSense, Ad Manager, AdMob) | The TCF is probably not required. Cookie consent is still required under the GDPR and the ePrivacy Directive, but not through the TCF specifically. |
Whether your website needs the TCF at all comes down to the last two rows. Google requires a CMP certified for the TCF from publishers using its ad products, not from sites that only run Google Analytics or Google Ads conversion tags, which rely on Google Consent Mode v2 instead. Publishers who rely on a commercial CMP should still verify the output rather than assume it.
Decode a TC string to check for the disclosed vendors segment
Open your website in a browser with no existing consent cookies (a private window works). Interact with the consent banner: accept all, then open your browser's developer console and run:
__tcfapi('getTCData', 2, function(tcData, success) { console.log(tcData.tcString); });
Copy the resulting TC string and paste it into a TC string decoder, such as the TCF string decoder linked at the end of this article, which supports v2.0, v2.2 and v2.3. Look for the disclosed vendors segment in the output. If it is present and includes the vendors configured in your CMP, including Google (755), your site is generating v2.3 strings. If it is missing, your CMP is still writing v2.2-format strings.
Check your Google error report
If you run Google AdSense, Ad Manager, or AdMob, download your TCF error report to see whether error 1.4 is appearing. In Ad Manager, it is under Admin > EU user consent. AdSense and AdMob have the same report on their own "EU user consent" pages.
The report covers the last 7 days and is only available if errors have been detected. No report means no detected issues, but it is still worth decoding your TC string independently.
Older TC strings stored in browsers stay valid
IAB Europe's transition guide says that TC strings created before 28 February 2026 without a disclosedVendors segment remain valid after that date. Google's page says it will continue accepting TCF v2.1 and v2.2 strings generated before 28 February 2026, in line with IAB TCF policy.
This means you do not need to force a mass re-consent. Your existing visitors' stored consent strings keep working until they expire or the visitor updates their preferences. At that point, the CMP must generate a new string under v2.3 rules.
IAB Europe states that CMPs should not be required to show the consent interface again purely for the v2.3 transition. If your CMP kept records of which vendors were disclosed when a TC string was first created, it may update existing strings to include the disclosed vendors segment, without changing their lastUpdated field. If it did not keep those records, the string is replaced the next time a visitor renews or changes their choice.
TCF v2.3 and Google Consent Mode v2 do different jobs
TCF v2.3 and Google Consent Mode v2 are separate mechanisms that serve different but related purposes. The TCF communicates consent signals across the ad tech supply chain through a standardised TC string. Google Consent Mode controls how Google tags (Analytics, Ads, Floodlight) behave based on consent status.
Publishers who use both need both to agree. Your CMP generates the TC string (now v2.3) and sends consent signals to Google tags through Consent Mode. If the TC string is invalid, Google's ad products report a TCF error even if the Consent Mode signals are correct, because ad requests through Ad Manager, AdSense and AdMob read the TC string.
After migrating to v2.3, test your Google Consent Mode integration separately. Confirm that ad_storage, analytics_storage, ad_user_data and ad_personalization signals still pass correctly when consent is granted and when it is denied.
Steps for publishers still running v2.2 strings
If you have not yet migrated, start with your CMP provider. Ask whether their solution generates TCF v2.3 strings with the mandatory disclosed vendors segment, and whether the update needs a setting in the dashboard or a newer script version. IAB Europe publishes a list of registered CMPs.
Verify that Google (vendor ID 755) is included in your disclosed vendors list. Error 1.4 triggers specifically when Google is missing from, or not properly flagged in, the disclosed vendors segment. Check your CMP's vendor configuration and make sure Google Advertising Products is included.
Review your vendor list while you are in there. Each vendor in the string adds to its length, and the Global Vendor List runs to well over a thousand vendors. Remove vendors you no longer work with.
Test thoroughly. Generate a fresh consent string, decode it, and confirm the structure. Then check your Google error report 24 to 48 hours later to see if any 1.4 errors appear.
For publishers with custom CMP implementations
If you built your own CMP, you need to update your TC string encoder. The disclosedVendors segment must appear immediately after the core segment, identified by segment type ID 1 (binary 001). The segment contains a MaxVendorId field followed by either a bit field or range encoding of vendor IDs. Set the bit for each vendor that your CMP interface actually displays to the user.
IAB Tech Lab maintains the official TypeScript library iabtcf-es on GitHub. If you are not already using it, consider it as your string encoding reference rather than maintaining a custom encoder.
The vendors you disclose must match the tags you load
A valid TC string is only one part of a working TCF setup. The vendors you disclose in the consent interface must match the vendors actually operating on your site. If your banner lists 80 vendors but your site loads tags from 95, you have a transparency gap that no string format can fix.
Regular scanning helps catch this drift. A cookie scanner lists the first-party and third-party cookies your pages set and the vendors they belong to, so you can compare them with the vendors your CMP discloses. Tag drift is common on sites where several teams manage ad integrations, third-party widgets or A/B testing tools. A quarterly scan is a reasonable baseline, and monthly is better if you often add or change integrations.
Since 2018 the TCF has gone through v1.1, v2.0, v2.2 and now v2.3, each responding to regulatory pressure, enforcement and technical gaps. On 7 January 2026 the Belgian Market Court annulled the APD's 2023 validation of IAB Europe's action plan, according to IAB Europe's statement on the ruling, and the APD now has to take a new decision. The findings that TC strings are personal data and that IAB Europe is a joint controller for them still stand. Treat your CMP and TCF integration as ongoing infrastructure that needs monitoring and testing, like your ad serving stack itself.
Short answers on TCF v2.3
What is the disclosed vendors segment in TCF v2.3?
The disclosed vendors segment is a mandatory part of the TC string that records which vendors were actually shown to the user in the consent management platform's interface. Each vendor ID is represented by a binary bit: 1 means the vendor was disclosed, 0 means it was not.
Do I need to show the cookie banner again after upgrading to TCF v2.3?
No. IAB Europe has stated that CMPs should not be required to show the consent interface again for this update. The new TC string is generated the next time a visitor renews or changes their choice.
What does Google TCF error code 1.4 mean?
Error 1.4 means the disclosed vendors section in the TC string is missing, malformed, or does not include Google (vendor ID 755). Google's troubleshooting page says that in this case Google was not able to operate on the request.
Will my old consent strings from before March 2026 stop working?
No. IAB Europe says TC strings created before 28 February 2026 without a disclosed vendors segment remain valid, and Google says it will continue accepting v2.1 and v2.2 strings generated before that date. Strings generated on or after 1 March 2026 must follow v2.3.
Is the TCF legally required or just a Google requirement?
The TCF itself is a voluntary industry standard, not a legal requirement. However, Google requires a certified CMP that uses the TCF from publishers serving ads through Ad Manager, AdSense, or AdMob in the EEA, UK, and Switzerland. If you do not serve ads through those products, you still need cookie consent under the GDPR and the ePrivacy Directive, but not through the TCF specifically.
Does Kukie.io generate TCF v2.3 strings?
No. Kukie.io is not a TCF CMP and does not generate TC strings. It offers Google Consent Mode v2 for sites that do not need the TCF, and a free TCF string decoder to check the strings another CMP writes.
Does TCF v2.3 affect websites outside of Europe?
Google's TCF requirement applies to ad requests from the EEA, UK, and Switzerland. Traffic from the US, Asia, and other regions is not affected. Your CMP should apply TCF logic only when it detects a visitor from a covered jurisdiction.
Check what your CMP writes
If your Google error report shows code 1.4, or you have not checked yet, decode a fresh TC string from your own site. The TCF string decoder shows every segment, including the disclosed vendors, with vendor names from the Global Vendor List, and the string never leaves your browser.
