Reading Your Own TCF Consent String: What the CMP Actually Stored
Open your own site in a private window right now, and try to accept or reject your own cookie banner using nothing but the Tab key. If you cannot find the buttons, or if Tab keeps cycling through the same three links forever, your consent platform just failed the very first interaction a real visitor has with your site. This is one of the fastest, most satisfying bugs to fix in all of web accessibility, and it is usually a few lines of focus-management JavaScript that some vendor shipped once and nobody has looked at since.
The stakes changed on June 28, 2025, when the European Accessibility Act started applying. A banner on a covered service has to meet WCAG 2.1 Level AA, and WCAG 2.2, the current version, adds criteria that banners fail constantly. An inaccessible banner is no longer just a bad experience. Under the EAA it is a compliance failure, and under GDPR Article 7 it can mean the consent was never validly given, because a visitor who cannot operate the interface cannot meaningfully choose.
A TCF consent string is a compact encoded record of which vendors and purposes a visitor agreed to, and which version of the vendor list it was collected against. You can decode it with a public decoder, and you should, because the string is the evidence your site will show a regulator, and a string that names the wrong vendors is a liability, not a record.
What is actually inside the string
The Transparency and Consent Framework string is a base64 encoded blob, and it carries more than a yes or no. It names the CMP ID, the version of the Global Vendor List it was collected against, the consent for each purpose, the legitimate interest claims, and the list of vendors the visitor allowed. The string is what gets passed to vendors and ad tech, and it is what they rely on to decide whether they may process the visitor's data.
The important part is the vendor list version. The Global Vendor List changes as vendors join, leave, or change purposes. A string collected against version 300 says nothing about the vendor list at version 320. If your CMP does not record which version each string used, your consent records are undated evidence, and undated evidence is weak evidence.
How to read your own strings in five minutes
Open your site, accept the banner, then open the browser developer tools and look for the __tcfapi calls or the consent cookie your CMP sets. Copy the string value and paste it into a public TCF decoder. The decoded view lists every purpose and vendor with a yes or no beside it. Check three things: does the vendor list version match the current list, does the purpose list match what your privacy policy promises, and does the vendor list match the vendors actually loading on the page.
The mismatch to look for is a vendor loading on the page that the string says no to, or a vendor the string says yes to that is not on the page at all. The first is processing without consent. The second is a stale string, probably collected before a vendor list change and never refreshed. Both show up in this five minute check, and both are invisible until you run it.
Making the string part of the routine
Add a monthly string check to the same routine as the consent record review. Decode a fresh string from a test browser, confirm the vendor list version is current, and confirm the purposes match the policy. Log the date and the version. If the CMP updates its vendor list, the next string check should show the new version, and visitors whose strings predate the change should have been re-prompted.
Keep the decoded strings with the consent records, not just the encoded blobs. A regulator or an auditor who has to decode your evidence themselves will not be patient about it. The readable version is the record, and the blob is just how it travels.
Keep reading: When Your CMP Vendor Changes Subprocessors, Your Consent Records Move Too, The Cookie Banner Keyboard Trap: Test Yours With Tab Alone, and Consent Evidence Is a Timeline. Keep the Versions. cover the nearby cases in this series.
Frequently asked questions
What is a TCF consent string?
It is the encoded record of a visitor's TCF consent: which vendors and purposes they agreed to, and which version of the Global Vendor List was current when they agreed. Vendors read it to decide whether they may process the visitor's data.
Why does the vendor list version matter?
Because the list changes over time. A string collected against an old version may name vendors who have left or miss vendors who joined. The version ties the consent to the list that was actually shown.
How do I decode a consent string?
Copy the string from the CMP cookie or the __tcfapi response in developer tools, and paste it into a public TCF string decoder. It will list every purpose and vendor with the visitor's choice beside each one.
What if the string says yes to a vendor that is not on my site?
The string is stale, probably collected before a vendor list change. Re-prompt the affected visitors so their stored consent matches the current vendor list.