What is an IAB TCF consent string?

A TCF (Transparency & Consent Framework) string is a compact base64url record that a Consent Management Platform writes to store a user's ad-tech consent choices — which purposes, special features, and vendors they allowed. Ad tags and OpenRTB requests carry it so downstream vendors know what they may do.

Why does the decoder show vendor and purpose numbers instead of names?

Vendor and purpose names live in the IAB Global Vendor List, which is loaded over a network. This tool decodes only the string you paste and makes no network calls, so it shows the numeric ids exactly as encoded. Look an id up in the current Global Vendor List to get the vendor name.

Where do I find the TC string to paste?

It is stored in the euconsent-v2 cookie, returned by the CMP's __tcfapi('getTCData', ...) call, and passed in an OpenRTB bid request as user.ext.consent. Copy any of those base64url values and paste it into the decoder.

What is the difference between service-specific and global scope?

The isServiceSpecific bit records whether consent was stored for one site or service (true) or in the shared global consensu.org scope (false). The decoder surfaces this bit so you can tell how portable the signal is across properties.

Does decoding a TC string change or re-sign it?

No. Decoding is read-only — it interprets the existing bits without re-encoding, re-signing, or altering the string. Your original TC string is unchanged and is only ever read locally in your browser.

Can it read publisher restrictions and extra segments?

Yes. It fully decodes the core segment and lists publisher purpose restrictions with their restriction type and affected vendors. Fields a string does not include — such as absent optional segments — simply show as empty.

TCF Consent String Decoder

Decode an IAB TCF v2.2 consent string in your browser to see the CMP metadata, purpose and vendor grids, and publisher restrictions.

The TCF Consent String Decoder runs entirely in your browser. The consent string you paste is decoded on your device, is never uploaded to ArrayKit, and no Global Vendor List or remote endpoint is contacted.

Open the TCF Consent String Encoder

About TCF Consent String Decoder

The TCF Consent String Decoder unpacks an IAB Transparency & Consent (TC) string so ad-ops and privacy engineers can see exactly what a CMP recorded. Paste the base64url string and it decodes the core segment locally: the CMP id and version, the screen and language the choice was captured on, the created and last-updated timestamps, the Global Vendor List version, and the TCF policy version. It then expands every bitfield into readable id lists — purpose consents, purpose legitimate interests, special feature opt-ins, vendor consents, vendor legitimate interests, and any publisher restrictions. Use it to debug a failing consent handshake, audit what a tag actually stored, or confirm a value before it reaches your ad server. The string is decoded in your browser and never leaves your device.

Features

Decodes IAB TCF v2.2 core-segment metadata: CMP id, version, screen, and consent language
Expands purpose consents and purpose legitimate interests into readable id lists
Shows special feature opt-ins alongside vendor consent and legitimate-interest grids
Surfaces publisher purpose restrictions with their restriction type and affected vendors
Displays created and last-updated timestamps plus the Global Vendor List version
Flags service-specific vs global scope, non-standard texts, and OOB support
Copy any id list as a comma-separated string for a bug report or ticket
Runs entirely in your browser — the consent string is never uploaded

How to use the TCF Consent String Decoder

Copy the TC string from a CMP cookie, a __tcfapi callback, or an OpenRTB user.ext.consent field
Paste it into the decoder, or click Sample to load an example TC string
Read the CMP metadata, then scan the purpose, special-feature, and vendor grids
Copy any id list to share the exact consent state with your team

Example

Input

COvFyGBOvFyGBAbAAAENAPCAAOAAAAAAAAAAAEEUACCKAAA

Output

CMP 27 · policy v2 · language EN · GVL 15
purposeConsents: 1, 2, 3
vendorConsents: 2, 6, 8

A core-only TC string decoded to its CMP metadata and consent grids.

Common errors & troubleshooting

The decoder reports that the string is not a valid TC string. — Paste the whole base64url TC string with no surrounding quotes or line breaks. A truncated core segment or a URL-encoded copy (%3D in place of =) will fail to decode.
The purpose or vendor lists look shorter than expected. — A TC string only stores ids the CMP explicitly set. Ids that are absent were not consented to. Confirm you pasted the full string and not just the segment before the first period.
The timestamps look off by several hours. — TCF timestamps are stored at day-level UTC precision. The decoder shows them in UTC, so convert to your local time zone before comparing them against a local log.
You expected vendor names but only see numbers. — Vendor and purpose names come from the IAB Global Vendor List, which this tool does not fetch. Match the numeric id against the Global Vendor List version shown in the metadata.

Frequently asked questions

What is an IAB TCF consent string?: A TCF (Transparency & Consent Framework) string is a compact base64url record that a Consent Management Platform writes to store a user's ad-tech consent choices — which purposes, special features, and vendors they allowed. Ad tags and OpenRTB requests carry it so downstream vendors know what they may do.
Why does the decoder show vendor and purpose numbers instead of names?: Vendor and purpose names live in the IAB Global Vendor List, which is loaded over a network. This tool decodes only the string you paste and makes no network calls, so it shows the numeric ids exactly as encoded. Look an id up in the current Global Vendor List to get the vendor name.
Where do I find the TC string to paste?: It is stored in the euconsent-v2 cookie, returned by the CMP's __tcfapi('getTCData', ...) call, and passed in an OpenRTB bid request as user.ext.consent. Copy any of those base64url values and paste it into the decoder.
What is the difference between service-specific and global scope?: The isServiceSpecific bit records whether consent was stored for one site or service (true) or in the shared global consensu.org scope (false). The decoder surfaces this bit so you can tell how portable the signal is across properties.
Does decoding a TC string change or re-sign it?: No. Decoding is read-only — it interprets the existing bits without re-encoding, re-signing, or altering the string. Your original TC string is unchanged and is only ever read locally in your browser.
Can it read publisher restrictions and extra segments?: Yes. It fully decodes the core segment and lists publisher purpose restrictions with their restriction type and affected vendors. Fields a string does not include — such as absent optional segments — simply show as empty.

Related tools

TCF Consent String Encoder — Build an IAB TCF v2.2 consent string from purposes, vendors and CMP fields.
GPP String Decoder — Decode an IAB GPP string into its header and each embedded consent section.
US Privacy String Decoder — Decode a US Privacy (CCPA) string like 1YNN into plain-language opt-out fields.
OpenRTB Bid Request Generator — Build a valid OpenRTB 2.5 or 2.6 bid request JSON from a form, with CTV presets.
VAST Macro Expander — Browse VAST 4.x macros and expand a tracking URL with sample or custom values.
ads.txt Validator — Validate ads.txt and app-ads.txt records against the IAB spec, line by line.