Read exactly what a TC string consents to
When you debug a Consent Management Platform (CMP) integration, you often have an opaque euconsent-v2 value and need to know what it actually permits. This decoder reads the IAB TCF v2.x core segment directly in your browser and shows the metadata (CMP ID, version, timestamps, consent language) plus the user’s consented purposes, legitimate interests, special features, and the vendor IDs that have consent.
How it works
A TC string is a base64url-encoded bit string. The decoder:
- Base64url-decodes the core segment (everything before the first
.) into a bit array, mapping each character to 6 bits. - Reads the fixed-position fields of the TCF v2 core: version (6 bits), created and last-updated timestamps (36 bits each, in deciseconds), CMP ID (12 bits), CMP version (12 bits), consent screen, consent language (12 bits = two 6-bit letters), vendor list version (12 bits), and the TCF policy version.
- Reads the Purpose Consents (24 bits → purposes 1–24, of which 1–11 are standard) and the Purposes LI Transparency bitfield, plus the 12-bit Special Feature Opt-ins.
- Reads Vendor Consent: a max-vendor-id field, then either a bitfield (one bit per vendor) or a range encoding (a count of ranges, each a single ID or a start–end pair).
All of this is integer and bit arithmetic — no library, no network.
Notes and example
Paste only the core segment if your string contains additional segments separated by dots (disclosed vendors, publisher TC) — those use different layouts and are not needed for the core consent view. A typical v2 string begins with C because the 6-bit version field of 2 plus the high bits encodes to that character. Because decoding is local, you can paste live production consent strings while debugging a CMP without any privacy concern. The purpose numbers follow the IAB Global Vendor List definitions, so cross-reference them against the official purpose list when interpreting a user’s choices.