TCF Consent String: Reading What the Browser Actually Stored

The TCF consent string is a small piece of text that carries the whole consent decision, and most sites never look at what is actually in it. It is stored in a cookie, passed to vendors, and decoded by anyone who cares to read it. If the string says a vendor has consent when the visitor said no, the string is the proof, and the vendor list is the lie.

The string is the record, not the banner

The Transparency and Consent Framework, TCF, is IAB Europe's standard for passing consent signals between publishers, vendors, and advertisers. The consent string is a compact, encoded record of the visitor's choices, stored in a cookie and passed to vendors, so they know what they are allowed to do with the data. It is the record that matters, not the banner, because the banner is what the visitor saw and the string is what the vendors received. If the two disagree, the string is the one that counts, and the vendor list is the lie.

That is why the string has to be checked after every consent change, not just after the first one. A visitor who changes their mind, withdraws consent, or updates a purpose should see the string change to match, and if it does not, the site is still passing the old consent to vendors who should no longer have it. The string is the audit trail, and an audit trail that does not update is not an audit trail.

How to read it

Decode it with a consent string decoder, which turns the encoded string into a readable list of purposes and vendors. Check the purposes first, then the vendors, then the legitimate interest claims. The purposes are the what: storage, personalisation, ad selection, and the rest. The vendors are the who: the companies that receive the data. The legitimate interest claims are the why: the vendors who claim they do not need consent, and who have to be checked separately.

The vendor list is long, often over a thousand vendors, and the consent string is the only place where the visitor's actual choices are recorded. A first layer that lists a thousand vendors is a list nobody reads, which is why the string matters more than the list. That is the same problem the buried refuse link names on the same site: the first layer is built to be skimmed, not read, and the string is the record that has to be right.

The failure that shows up in the string

The most common failure is a vendor that appears in the consent string without the visitor's consent. It happens when the consent management platform adds a vendor to the string by default, or when a vendor is added to the list after the visitor consented and the string is not updated. Either way, the vendor is processing data without a lawful basis, and the string is the evidence. That is a compliance failure, and it is also a trust failure, because the visitor's choice was recorded and then ignored.

The fix is to check the string after every consent change, and to check it with a decoder, not by reading the cookie. A cookie is a string of characters. A decoder is a tool that turns it into a list, and the list is the thing that can be checked. If a vendor appears in the list that the visitor never consented to, remove the vendor, update the string, and check again. That is the whole test, and it takes five minutes.

The test that catches it

Open the site, give consent, then decode the string. Write down the vendors. Withdraw consent, then decode the string again. The vendors should be gone, or marked as not consented, and if they are still there, the site is still passing the old consent. That is the test, and it is the one that catches the failure that the banner never shows.

Then do the same test after a CMP migration, because that is when the string is most likely to be wrong. A migration that copies the vendor list but not the consent state is a migration that has to be checked, and the string is the place to check it.

Frequently asked questions

What is the TCF consent string?

The Transparency and Consent Framework, IAB Europe's standard for passing consent signals between publishers, vendors, and advertisers. The consent string is a compact, encoded record of the visitor's choices, stored in a cookie and passed to vendors, so they know what they are allowed to do with the data.

How do I read a TCF consent string?

Decode it with a consent string decoder, which is a tool that turns the encoded string into a readable list of purposes and vendors. Check the purposes first, then the vendors, then the legitimate interest claims. If a vendor appears in the string that the visitor never consented to, the string is the proof.

Can a vendor appear in the consent string without consent?

Yes, and it is the most common one. A vendor that appears in the consent string without the visitor's consent is a vendor that is processing data without a lawful basis, and the string is the evidence. The fix is to check the string after every consent change, not just after the first one.

Why does the vendor list matter if nobody reads it?

Because the vendor list is long, often over a thousand vendors, and the consent string is the only place where the visitor's actual choices are recorded. A first layer that lists a thousand vendors is a list nobody reads, and the string is the record that matters. That is why the string has to be right, even if the list is not read.