How to Parse TLVs in JavaScript

Dear Readers,

One of the nice things about chip cards (ICCs) is that the data that comes out of them is virtually always supplied in a standard format, called BER-TLV. In plain English: Basic Encoding Rules, Tag-Length-Value (a quaint but informative article about it can be found here).

The BER-TLV format is one of the ASN.1 (Abstract Syntax Notation) encodings defined by ITU X.690, which is a very old set of standards dating to the primordial predawn of the Internet.

Chip cards use the TLV scheme to encode card data. At its simplest, the Tag-Length-Value scheme just means that if you have a tag called (say) “5A” and its value is 8 octets represented by (for example) successive hex values “41 11 12 34 56 78 9A BC,” then the TLV encoding will look like 5A084111123456789ABC, where 5A is the tag, 08 is the length, and 4111123456789ABC is the value.

EMVCo (the card-issuer consortium behind the whole chip-card thing) defines a bunch of standard tags for chip-card transactions. For example 5A always encodes the PAN (primary account number, or card number), 9F02 encodes the Authorized Amount of a transaction, 5F2D encodes Language Preference, and so on. The complete list of EMVco-defined tags (and their meanings) can be found at

Given that TLVs encode their own length, it should be a snap to parse TLV data, right?

Well, yes. Mostly. Kind of.

If every tag had a simple one-byte identifier (like 5A), it really would be super-duper-easy to parse a TLV stream. But the TLV scheme wouldn’t be very useful if identifiers could only ever take on one of just 256 possible values.

To make tag identifiers extensible, Basic Encoding Rules allow for the possibility of multi-byte tags. The rules say that if the bottom 5 bits of the first tag byte are set, then more tag-identifier bytes follow. In subsequent bytes, the top bit is set if more bytes follow, whereas the top bit is zero in the final byte. So for example, 5F24 is a legal 2-byte tag identifier, DFEF01 is a legal 3-byte tag, and so on.

EMVCo (which incorporates BER-TLV by reference in Book 3, Annex B, of the EMV specifications) also allows for the concept of “wrapper” tags, to enable hierarchical parent-child relationships (or nesting) among TLVs. Under EMV rules, if the sixth bit of a tag’s first byte is set, the tag is said to be “constructed” (I prefer the term compound). Thus, a 3-byte tag FFEE01 could be used to wrap (fictional) TLVs of 3F0188 and 3F025544 as follows: FFEE01073F01883F025544. The parent tag, FFEE01, has 7 bytes of data, consisting of a 3-byte TLV and a 4-byte TLV. Groups of tags can be nested to any desired depth using this scheme.

Note carefully, the Length byte of a TLV can also be multi-byte. Here, the extensibility rule (taken from EMV Book 3 Annex B2) is:

A length byte with the top bit set will mean you have to treat the bottom 7 bits as the “length of the Length.” In other words, a Length byte of 0x82 means that there are two bytes of Length info (in the two bytes that follow). In the (fictional) TLV represented by 5F0F8103AABBCC, the tag is 5F0F, the length of the Length is one byte, the actual Length is 3 bytes, and the Value is AABBCC.

Clear as mud, right?

So, knowing all this, we’re able to create a fully general recursive-descent TLV parser in about 75 lines of JavaScript, as follows.

//  ===============  BER-TLV PARSER  ================

// All known tags (EMVCo and ID TECH):

_KnownTags =
















































// ‘data’ should look like “95050010203000…” etc.

// In other words: TLVs, serialized, as one big string.

// A TLV object is returned. Use it to look up Values by Tag name.

// TLV[’95’] will contain the value of tag 95.

// TLV[‘9F26’] will contain the value of tag 9F26, etc.

function parseTags( data ) {


var TLV = {}; // results go here


// inner method

function readData( amt, tag ) {


data = data.slice( amt ); // get past tag bytes


// find the Length (the L in TLV)

var length = data.slice(0,2);  // read two nibbles

data = data.slice(2); // get past those nibbles

length = 1 * (“0x” + length);  // cast to Number


if (length & 0x80) {  // high bit set? (EMV Book 3 Annex B2)

highBitsByteExisted = 1;

var lengthOfLength = length & 0x1F;

lengthOfLength *= 2; // convert to nibbles!

length = data.slice(0, lengthOfLength);

data = data.slice( lengthOfLength ); // get past actual length

length = 1 * (“0x” + length);  // cast to Number



length *= 2;  // number of nibbles of data to read


var V = data.slice(0, length);


// push the V onto the TLV array

TLV[tag] = V;


// if it was a constructed tag (FFEE01, e.g.) recurse:

if ( tag.slice(0,2) == ‘FF’ ) {

tmptlv = parseTags( V );

for (var t in tmptlv)

TLV[t] = tmptlv[t];


data = data.slice( length ); // get past the data




var amtRead,tag;


while( THE_SUN_SHINES ) {


if ( data == “”) break; // loop ends


for ( amtRead = 2; amtRead <= 6; amtRead += 2 )

if ( (tag = data.slice(0,amtRead).toUpperCase() ) in _KnownTags )


else if ( amtRead == 6 ) {  // no known tag?

data = data.slice( 2 );  // no tag found; just advance 2 chars

console.log( “Expected a tag, found none. Data: n” + data );

} // if not 3-byte


readData( amtRead, tag ); // This method shortens data (by amtRead) each time

}  // while loop


return TLV;   // return an object in which TLV[ key ] == V


The tactic we use here is brain-dead simple:

First, make available a big dictionary of tag identifiers, containing all known EMVCo (industry standard) tags, plus all known ID TECH proprietary tags. We call this dictionary _KnownTags, and you can test an identifier like ‘5A’ for existence by seeing if _KnownTags[ ‘5A’ ] returns true.

Next: Parse!

Our parsing algorithm is super simple:

Read two nibbles at a time into a tag variable, and test whether the tag exists in the dictionary. All tags in the dictionary will be one, two, or three bytes long, so if we read 6 nibbles without finding a known tag, just advance the reading frame by 2 nibbles and continue on like nothing happened (after emitting a console message saying “Expected a tag, found none”). If you want to be fussy and throw an exception here, you can, but my philosophy is that (depending, of course, on the circumstances) a parser should by default be fail-soft (fault tolerant), in case you still want to use the rest of the parsed data.

Once a tag is found, use a worker method, in this case an inner function called readData(), to read past the tag, read the Length, and use the Length to read the Value. (Here, we need to be careful to check the top bit of the presumed Length, to see whether we need to follow the length-of-the-Length extensibility hack  rule mentioned earlier.)

Put the Value into a storage object under a lookup key of tag.

At the end, return the storage object.

So let’s try a real-world example. Suppose you’ve got an ID TECH Augusta chip-card reader, and you’re using it in keyboard mode to capture Quick Chip data. The data that streams out of the device when you dip a card might look like:


This is a big block of TLV data that begins with an ID TECH proprietary tag of DFEE25. (You can learn more about what ID TECH’s tags mean by downloading the ID TECH TLV Tag Reference Guide from Most of the tags in this block, however, are industry-standard EMVCo tags. If we assign the block, as a string, to a JS variable called tagblock, and then load the above parser and run it with parseTags( tagblock ), we’ll get back an object with tags and values, like this:

50: 4465626974204D617374657243617264
57: 9F7E8B5A206B4F2CEA931148704EC549EDBAB728643E9197
82: 3900
84: A0000000041010
95: 0400000000
DFEE25: 0002
DFEE26: 2000
DFEE12: 62994900000000000074
5A: B5DECD79E3D200A6DE66A20C18DE80AC
5F20: 2F43484950205445535420434152442020202020202020202020
5F24: 180131
5F25: 150101
5F28: 0840
5F2A: 0840
5F2D: 656E
5F34: 00
5F57: 00
4F: A0000000041010
8C: 9F02069F03069F1A0295055F2A029A039C019F37049F35019F45029F4C089F3403
8D: 910A8A0295059F37049F4C08
8E: 00000000000000004203440341031E031F03
9C: 00
9F02: 000000000000
9F03: 000000000000
9F10: 0110200005620400000000000000000000FF
9F26: C837A85C5DFE7573
9F27: 00
9F34: 1E0300
9F36: 0266
9F37: BB8050C9
9F39: 07
9B: E800
8A: 5A33
DFEF4C: 002100000000
DFEF4D: AA839B4B402083DDEC00614D1703B139A07586453583B4A03AB333FB210FD1CD4F8AC3603D75688E

Some of these tags are empty. Some (like 9F27) contain a Value of 00. Some are encrypted. But basically, you have all the tags you need, right here, to run an EMV transaction.

About Ambimat Electronics:

With design experience of close to 4 decades of excellence, world-class talent, and innovative breakthroughs, Ambimat Electronics is a single-stop solution enabler to Leading PSUs, private sector companies, and start-ups to deliver design capabilities and develop manufacturing capabilities in various industries and markets. AmbiIoT design services have helped develop SmartwatchesSmart homesMedicalsRobotics, RetailPubs and brewerySecurity 

Ambimat Electronics has come a long way to become one of India’s leading IoT(Internet of things) product designers and manufacturers today. We present below some of our solutions that can be implemented and parameterized according to specific business needs. AmbiPay, AmbiPower, AmbiCon, AmbiSecure, AmbiSense, AmbiAutomation.

To know more about us or what Ambimat does, we invite you to follow us on LinkedIn or visit our website.


How to Parse TLVs in JavaScript

Bits and Bytes
A Chip-Card Reader that Outputs Text