Hex, ASCII, EBCDIC & BCD Converter

Why EBCDIC is here

Because mainframe acquirers still speak it. If you are integrating with an endpoint running on z/OS, the hex dump you are staring at is very likely code page 037, and reading it with an ASCII table produces convincing nonsense. The giveaway: EBCDIC digits are F0-F9 and uppercase letters live at C1-C9, D1-D9, E2-E9, so text looks like a run of high bytes rather than the 0x30-0x7A range you expect.

Note the discontinuity in the letter ranges: EBCDIC letters are not contiguous, which is why naive c - 'A' arithmetic breaks on mainframe data.

Hex versus packed BCD

These look identical and mean different things. 000000001500 as hex is the integer 5376; as packed BCD it is the decimal digits 000000001500. EMV amounts (tag 9F02) and dates (tag 9A) are packed BCD, two decimal digits per byte, so 250810 is the 10th of August 2025, not 0x250810. The TLV parser already knows which tags are BCD and reads them that way, so a whole chip trace does not need converting field by field.

The tell is that packed BCD never contains a nibble above 9. When this tool sees a value where every nibble is 0-9, it points out that BCD is a possible reading, because assuming hex there is a common and expensive mistake.

Which EMV values convert, and how

A chip trace arrives as one long hex string, but the values inside it are not all the same kind of data and EMV does not leave you to guess which is which. Every tag carries a format in Book 1: ans and an are ASCII text, n and cn are packed BCD digits, and b is raw binary that means nothing at all until a bit table is applied to it.

So 5F20 (cardholder name), 50 (application label) and 9F12 (application preferred name) are ans: convert hex to ASCII and the text is there. 9F02 (amount), 9A (date), 9F21 (time) and 5F24 (expiry) are n: read them as BCD and the digits are already the answer, with no arithmetic in between. 95 (TVR), 82 (AIP) and 9F27 (CID) are b, and converting those to text or decimal is a category error. They want the bit field decoder instead.

Working through a whole trace tag by tag here is the slow way round, though. The TLV parser reads the structure and applies each tag's declared format as it goes. This tool is for the single value you have already isolated, or for data that has no TLV structure to parse in the first place.

Length prefixes

One place the ASCII/BCD distinction bites hard: ISO 8583 variable-length fields carry a 2- or 3-digit length prefix, and whether it is ASCII digits or packed BCD is an endpoint decision. A PAN of length 16 is 3136 in ASCII and 16 in BCD. Read it the wrong way and every subsequent field shifts, which is what a message that decodes cleanly for ten fields and then turns to noise almost always turns out to be.

Code page caveat

CP037 is the common US and international EBCDIC variant, and it is what this tool uses. Other code pages (CP273 for Germany, CP500 international, CP1047 for Latin-1) differ in a handful of punctuation positions. Letters and digits are stable across all of them, so if your text reads correctly but the brackets and the logical-not sign look wrong, you have a code page mismatch rather than a decoding error.