How to read an EMV TLV response

A hexadecimal dump becomes easier to understand when you can identify where each field starts and ends. In TLV data, each object contains a tag, a length and a value. A constructed object holds other TLV objects inside its value.

Start with a small example

Paste these synthetic bytes into the TLV Parser:

6F 11 84 07 A0 00 00 00 03 10 10 A5 06 50 04 56 49 53 41

The outer tag is 6F, an FCI Template. Its length, 11, means the value contains 17 bytes. Inside it, 84 07 introduces a seven-byte Dedicated File Name. The remaining A5 template contains tag 50, a four-byte Application Label whose value is the ASCII text VISA. This is a small structural example, not a complete application profile.

Count bytes, not characters

Two hexadecimal digits represent one byte. Spaces make the dump easier to read but do not contribute to a TLV length. A length that extends beyond the supplied input usually means the response was truncated or the bytes were assembled incorrectly.

For an APDU response, separate the trailing status bytes before parsing the data. A successful response commonly ends in 90 00; those bytes are not part of the TLV payload.

Structure is only the first check

Expand the parser tree to inspect nested values and offsets. Use the EMV Tag Dictionary to look up field names. A structurally valid object can still contain a value that is invalid for a particular card profile. Tag meanings, permitted lengths and mandatory fields need that profile’s rules.