What is a TCF consent string?

It is a compact, base64url-encoded record of a user's consent choices under the IAB Europe Transparency and Consent Framework. Ad-tech vendors read it to decide whether they may process personal data for purposes like ad personalisation and measurement.

Does this produce a fully spec-complete string with all segments?

It encodes the TC core string segment, which carries the version, timestamps, CMP fields, purpose consents, purpose legitimate interests, and a vendor consent bit field. It is intended for generating test payloads, not for replacing a certified production CMP that may append publisher and out-of-band segments.

Why are timestamps in the string?

The spec encodes Created and LastUpdated as deciseconds (tenths of a second) since the Unix epoch, each in 36 bits. They let downstream vendors know how fresh the consent record is. This tool stamps both with the current time.

What are the 24 purposes?

TCF v2 defines a standard list of processing purposes, for example purpose 1 (store and access information on a device) and purpose 3 (create a personalised ads profile). A user can consent to each independently, and some can also rely on legitimate interest.

Is anything sent to a server?

No. The entire bit-packing and base64url encoding runs in your browser. Your selected purposes and vendor IDs never leave the page, which makes it safe for QA use.

TCF Consent String Encoder (IAB v2.x)

The IAB Europe TCF v2 consent string (the euconsent-v2 value passed through __tcfapi) is how ad-tech vendors learn what a user agreed to. It is not JSON — it is a tightly bit-packed structure encoded as base64url. Hand-writing one is error-prone, and spinning up a full CMP just to get a test value is overkill. This encoder lets CMP developers and QA engineers select purposes, legitimate interests, and vendor IDs and get back a valid TC core string in seconds, entirely in the browser.

How it works

The TC string is a sequence of fields packed into a continuous bit stream, then base64url-encoded (6 bits per character, no padding). The core string this tool builds contains, in order:

Version (6 bits) — fixed at 2.
Created and LastUpdated (36 bits each) — deciseconds since the Unix epoch.
CmpId (12 bits) and CmpVersion (12 bits).
ConsentScreen (6 bits) and ConsentLanguage (12 bits, two letters at 6 bits each, A=0).
VendorListVersion (12 bits) and TcfPolicyVersion (6 bits).
IsServiceSpecific (1 bit), UseNonStandardTexts (1 bit), SpecialFeatureOptIns (12 bits).
PurposesConsent (24 bits) and PurposesLITransparency (24 bits) — one bit per standard purpose.
PurposeOneTreatment (1 bit) and PublisherCC (12 bits).
A vendor consent section: MaxVendorId (16 bits), an encoding flag (0 = bit field), then a bit field of that length.

Bits are written most-significant-first into a string of "0"/"1", then chunked into groups of six and mapped to the base64url alphabet A-Za-z0-9-_.

Example

Selecting purposes 1, 3, and 4 as consented, purpose 2 as legitimate interest, and vendors 1, 28, and 755 with CMP ID 7 produces a string beginning C (the base64url of version=2 followed by the timestamps). Paste it into a __tcfapi('getTCData', ...) test harness to exercise your vendor-gating logic.

Notes

This builds the core segment only — enough for the vast majority of testing — and stamps the current time into the created/updated fields. It is not a substitute for a certified production CMP, which may append publisher TC and allowed-vendor segments. All bit-packing happens locally; your selections never leave the browser.