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 1280; 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 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.

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.

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.