What Validation Means Here
A TCF CMP isn't valid because it renders a banner. It's valid because the strings it produces decode correctly, carry a registered CMP identity, and are delivered through the API the way vendors expect. IAB Europe verifies this against live installations as part of its ongoing monitoring, and it publishes a browser extension so you can check your own site before anyone else does. Get the encoding wrong and downstream vendors silently discard your signal, which means the consent you collected never reaches the ad stack.
This guide covers the technical bar, not the legal registration paperwork. For the publisher-facing view of who needs TCF and what changed across versions, see the TCF for publishers guide.
You Need a Registered CMP ID
Every TC String carries the id of the CMP that created it. That id is assigned by IAB Europe when you register and are approved as a CMP. It isn't cosmetic: vendors and validators look it up, and a string signed with an unregistered or placeholder id is treated as untrustworthy. The official encoding libraries enforce a floor here. The @iabtechlabtcf/cmpapi package refuses a CMP id below 2, because 0 and 1 are reserved for stub and testing states.
This is the one requirement you can't code your way around. You can build and test the entire runtime with a placeholder id, but the strings it emits are testing artifacts until a real registered id replaces it. Be honest with yourself about which mode you're in, because a demo that looks identical to production is exactly how a placeholder id ends up live.
The TC String Has to Decode Cleanly
The TC String is a base64url-encoded, bit-packed structure with a mandatory core segment and optional segments for disclosed vendors and publisher data. The core segment holds the CMP id, CMP version, the vendor list version you encoded against, the TCF policy version, the consent language, purpose consents and legitimate interests, special feature opt-ins, and the per-vendor consent vectors.
The only reliable way to know your string is valid is to decode it with the same library vendors use and check the fields came back as you set them. CookieBeam's runtime does exactly this in its validator: it runs the encoded string back through TCString.decode and surfaces the version, CMP id, vendor list version, policy version, and the full purpose and vendor vectors. If decode throws, the string is malformed, full stop. Round-tripping every string you generate in tests catches encoder bugs before a vendor does.
TCF 2.2 Changed How Vendors Read Consent
TCF 2.2, which CMPs had to implement by 30 September 2023, deprecated the getTCData command for vendors. In the web environment, a vendor with JavaScript access is now expected to register an addEventListener callback rather than call getTCData to pull the TC String. Your CMP still has to support the API, but the delivery model is event-driven.
Practically, that means your CMP must fire listener callbacks at the right moments: when the UI is shown, and when the user completes an action that changes consent. If your implementation only answers one-shot reads and never emits events, TCF 2.2 vendors won't pick up the updated string after a user changes their mind. CookieBeam's TCF layer wires its consent-update event into the CmpApi so that saving a new choice propagates a fresh string to every registered listener.
Encode Against the Right GVL Version
The TC String records which Global Vendor List version it was built against, and that number has to be real and current. The GVL moved to v3 with TCF 2.2 and is republished weekly at vendor-list.consensu.org/v3/vendor-list.json as vendors change their registrations. If you encode a vendor id that doesn't exist in the version you claim, or you claim a stale version, validation flags it.
This makes GVL freshness an operational requirement, not a one-time fetch. A CMP that cached the vendor list months ago is encoding against a list that no longer matches reality. The mechanics of loading, caching, and refreshing the list without bloating every page load are covered in the GVL management guide.
Check It With the CMP Validator
IAB Europe ships a CMP Validator Chrome extension that carries the TCF 2.2 requirements. Install it, load a page running your CMP, and it inspects the __tcfapi calls, the emitted TC String, and the UI behavior against the spec. It's the same class of check IAB runs during monitoring, so a clean pass in the extension is a good proxy for a clean pass in the real audit.
Use it as a gate, not an afterthought. Run it against a page with no prior consent, a page mid-interaction, and a page where a returning user changes their choice. Each state exercises a different part of the API contract, and the returning-user case is where event delivery bugs surface.
A Pre-Launch Checklist
- Real, registered CMP id in every production string (id 2 or higher, never the placeholder).
- Every generated string round-trips through
TCString.decodewithout throwing. - Listeners fire on UI shown and on consent change, so TCF 2.2 vendors get updates.
- Encoding uses a current GVL v3 version, refreshed on a schedule.
- The stub loads first so early vendor calls don't throw. See the stub loading guide.
- A clean pass in the IAB CMP Validator across no-consent, mid-flow, and returning-user states.