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.
What you can do here
- Debug euconsent-v2 values from tag logs.
- Verify CMP configurations before launch.
- Share decoded results with privacy or ops teams.
Before you start
- Paste a TCF v2 string (core or full string).
- Load the sample to see a valid format.
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.
About TCF String Decoder
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.
Best uses for TCF String Decoder
- Debug euconsent-v2 values from tag logs.
- Verify CMP configurations before launch.
- Share decoded results with privacy or ops teams.
How to use TCF String Decoder
- 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.
What to paste in
- Paste a TCF v2 string (core or full string).
- Load the sample to see a valid format.
What you should see
- Readable JSON with metadata and consent vectors.
- Purpose and vendor arrays ready to export or share.
Example checks
These are simple checks you can run when you want a real sample and a clear result to compare against.
Paste a TCF v2 string (core or full string).
Why run it: Debug euconsent-v2 values from tag logs.
What to look for: Readable JSON with metadata and consent vectors.
Load the sample to see a valid format.
Why run it: Verify CMP configurations before launch.
What to look for: Purpose and vendor arrays ready to export or share.
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.
Troubleshooting
What to look for
- Readable JSON with metadata and consent vectors.
- Purpose and vendor arrays ready to export or share.
Common issues
- Invalid or truncated strings will fail to decode.
- Publisher segments may be absent in some strings.
Best practices
- 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.
Related tools
More tools in the privacy / tcf 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.
- Cookie Sync Visualizer - Fetch a page and list likely cookie-sync or ID-match partners based on sync-like endpoints found in HTML resources. This is a useful first pass for privacy, identity, and header bidding investigations when you need to see which third-party domains look involved in sync behavior.
- US Privacy String Decoder - Decode IAB US Privacy strings into readable notice, opt-out, and LSPA flags for CCPA and US state privacy debugging.
- Consent Cookie Inspector - Parse cookie strings for common consent and privacy signals such as euconsent-v2, addtl_consent, US Privacy, and GPP cookies so teams can see which consent artifacts are actually present.
Related reading
More specific pages for the exact jobs this tool supports.
Decode TCF Consent for Vendor Audits
A consent-focused workflow for understanding who is allowed to do what in a TCF string.
Audit a TCF String From a CMP Support Ticket
A support-focused TCF decoding workflow.
Check Vendor Permissions Before a Bidder Launch
A pre-launch consent workflow for bidder onboarding.
Compare Two TCF Strings After a CMP Change
A comparative TCF page for CMP change management.
Verify Purpose 1 Consent Before Identity Testing
A consent-baseline workflow for identity-related testing.
Check Legitimate Interest Signals Before Partner QA
A legal-basis workflow for partner-facing TCF reviews.
Inspect Consent Cookies Before Partner Debugging
A privacy-signal workflow for auditing cookie presence before deeper QA begins.
Check CMP Markers Before a Privacy Rollout Review
A source-level CMP workflow for rollout reviews and post-migration audits.
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.
Helpful links
Standards & references
Official specs that inform how this tool interprets data.