Tool
TCF String Decoder
TCF String Decoder
Decode IAB TCF v2 consent strings into human-readable metadata, purposes, and vendor consent arrays. Paste a TC string from a CMP or euconsent-v2 cookie, and instantly see what it contains for QA, troubleshooting, and compliance checks. Everything runs client-side for privacy.
Paste a TCF string and see the consent metadata in plain JSON.
TCF String Decoder
Decode IAB Transparency & Consent strings into readable fields.
Uses this app’s cached GVL (last updated —).
Decoding runs locally using @iabtcf/core. Vendor names come from this app’s cached IAB GVL snapshot.
Decoded output
Expand, collapse, or search the JSON.Decode a TCF string to see details here.
Raw JSON (for copy/paste)
Summary
Key consent signals and versions.Decode a TCF string to view the summary.
How it works
The TCF String Decoder breaks down IAB Transparency & Consent Framework strings so you can inspect CMP settings, purpose consents, and vendor signals without guessing.
Use it to decode TCF strings, validate CMP metadata, and map consented vendors and purposes.
What you can do with it
- Quickly validate consent strings during QA.
- Surface CMP metadata like version, language, and policy version.
- See which purposes or vendors are consented at a glance.
Common tasks
- Debug euconsent-v2 values from tag logs.
- Verify CMP configurations before launch.
- Share decoded results with privacy or ops teams.
Quick steps
- Paste a TCF v2 string from your CMP or cookie store.
- Click Decode to parse the string locally.
- Review the JSON output for metadata, purposes, and vendor consents.
Related tools
More tools in the privacy category.
- Cookie Inspector — Parse and analyze Set-Cookie headers or page cookie dumps to surface security, scope, and privacy issues with remediation guidance. Useful for privacy, security, and ad ops teams to quickly understand cookie risks and fixes.
Before you start
- Paste a TCF v2 string (core or full string).
- Load the sample to see a valid format.
What you get
- Readable JSON with metadata and consent vectors.
- Purpose and vendor arrays ready to export or share.
Common pitfalls
- Invalid or truncated strings will fail to decode.
- Publisher segments may be absent in some strings.
Tips for best results
- Paste raw input so the tool can apply formatting consistently.
- If output looks wrong, validate the input for missing commas or tags.
- Use the example buttons above to sanity-check formatting and behavior.
Understanding the IAB TCF: How Consent Strings Encode User Choices
The Role of Consent Management in Digital Advertising
The General Data Protection Regulation (GDPR) and similar privacy laws require that users give informed consent before their personal data is processed for advertising purposes. In the digital advertising ecosystem, where dozens of companies may participate in a single ad impression — from the publisher's ad server to demand-side platforms, data management platforms, and measurement providers — communicating a user's consent choices to all parties is a significant technical challenge.
The IAB Europe Transparency & Consent Framework (TCF) provides a standardized solution. When a user interacts with a Consent Management Platform (CMP) — the cookie banner or consent dialog they see on websites — their choices are encoded into a compact string format that can be passed along the ad supply chain. Each party in the chain can decode this string to determine whether the user has consented to specific processing purposes and whether specific vendors are authorized to process data.
The TCF consent string is a densely packed binary structure encoded as a web-safe Base64 string. It contains metadata about the CMP that created it, the version of the TCF specification used, the date the consent was last updated, and bit vectors representing the user's choices for each purpose and vendor. Understanding what a consent string contains is essential for QA teams, privacy officers, and ad operations professionals who need to verify that consent is being captured and transmitted correctly.
What a TCF String Contains
A TCF v2 consent string packs a remarkable amount of information into a compact format. The core segment includes metadata fields: the specification version, the CMP ID and version, the consent screen number, the consent language, the vendor list version, and the policy version. These fields identify exactly which CMP captured the consent, when it was captured, and which version of the Global Vendor List (GVL) was used to present choices to the user.
The purpose consent and legitimate interest sections are bit vectors where each bit position corresponds to a specific processing purpose defined in the TCF specification. Purpose 1 (store and/or access information on a device), Purpose 2 (select basic ads), Purpose 3 (create a personalized ads profile), and so on each have their own bit. A value of 1 indicates the user consented to that purpose; 0 indicates they did not.
Vendor consent works similarly — each registered vendor in the Global Vendor List has a numeric ID, and the consent string includes bit vectors indicating which vendors the user has authorized. The GVL itself maps these vendor IDs to company names, purposes they require, and their privacy policy URLs. Decoding a consent string and cross-referencing it with the GVL reveals the complete picture of what the user consented to and which companies can process their data.
Common TCF Debugging Scenarios
QA teams decode TCF strings to verify several things. Before a CMP goes live, decoding the strings it generates confirms that user choices are encoded correctly — that consenting to all purposes actually sets all purpose bits, that rejecting a specific vendor actually clears that vendor's bit, and that the metadata fields are populated correctly. After deployment, decoding consent strings from production logs can diagnose why certain ads are not serving (the user may not have consented to the required purposes).
A common issue is version mismatch: a consent string created with an older GVL version may not include consent for vendors that were added in a later version. Another issue is segment handling: the TCF string can include optional segments for publisher-specific purposes and disclosed vendors, and not all CMPs populate these consistently. Decoding the string and examining each segment reveals these discrepancies clearly.
For privacy teams, decoded consent strings serve as audit evidence. Being able to show exactly what a consent string contains — which purposes were consented to, which vendors were authorized, when the consent was captured — supports compliance documentation and regulatory inquiries. The ability to decode these strings without relying on the original CMP provides independent verification of consent data.
Frequently asked questions
Is it free to use?
Yes. Core tools are free and accessible without signup.
Does it upload my data?
This tool runs locally in your browser. Data you paste or files you upload stay on your device and are not uploaded.
What if I spot a bug?
Please reach out via the Contact page with a reproduction example.
Where do vendor names come from?
Vendor names are mapped from the IAB Global Vendor List cached by the app.
Does it verify signatures or consent legitimacy?
No. It decodes the string and reports the data it contains.
Is the input uploaded?
No. Decoding runs locally in your browser.
Standards & references
Official specs that inform how this tool interprets data.