Reading EMV BER-TLV without a spec sheet

Every EMV response is a tree of Tag-Length-Value nodes. Once you can read one by eye, half the mystery drops out of card-present flows.

Based on notes from a 2023 kernel integration; written 2026-08.

The three moving parts

Every TLV node has three sections, in order:

1. Tag — one or more bytes identifying what the value is. The first byte's top two bits encode the tag class; bit 6 marks whether the value is constructed (contains nested TLVs) or primitive (opaque bytes).
2. Length — one byte for values under 128 bytes ("short form"), or a lead byte with the high bit set followed by that many length bytes for longer values ("long form").
3. Value — the actual data, whose interpretation depends on the tag.

Worked example

Take this fragment from a card selection response:

6F 12 84 07 A0 00 00 00 03 10 10 A5 07 50 05 44 45 42 49 54

Reading left to right:

• 6F — FCI Template (constructed). Length 12 (18 decimal). Contents follow for 18 bytes.
• Inside: 84 07 — DF Name, 7 bytes, value A0 00 00 00 03 10 10 (Visa AID).
• Then A5 07 — FCI Proprietary Template (constructed), 7 bytes.
• Inside that: 50 05 — Application Label, 5 bytes, value 44 45 42 49 54 which is ASCII "DEBIT".

That's it. Every EMV response is more of the same, plus a longer tag dictionary.

Multi-byte tags

When the low 5 bits of the first tag byte are all set (0b11111), the tag continues into the next byte(s). Read subsequent bytes while their high bit is set. That's how you get tags like 9F26 (Application Cryptogram) and 9F37 (Unpredictable Number).

Try it live

There's a browser-side parser at /production-kit/ber-tlv-dissector. Paste any EMV buffer; it renders the tree with tag dictionary lookups. Deterministic, offline, and it never leaves your browser.