Paste hex and read the same bytes two ways at once — an ASCII column and an EBCDIC (CP500) column — so you can tell at a glance which encoding you are holding.
0x / \x prefixes are stripped automatically. An odd number of hex digits raises an explicit error — nothing is silently truncated.Hex carries no meaning by itself — the meaning comes from the code page you read it with. The byte F1 is outside the printable range in ASCII, so it can only render as .; read as EBCDIC (CP500) it is the digit 1. That is why the dump above gives you two columns: the same row of bytes decoded as ASCII on the left and as EBCDIC on the right. Whichever column reads like language is your answer.
The most useful tells, visible from the raw hex alone:
| Content | ASCII | EBCDIC (CP500) |
|---|---|---|
| Digits 0–9 | 0x30–0x39 | 0xF0–0xF9 |
| Space | 0x20 | 0x40 |
| Uppercase A–Z | 0x41–0x5A, contiguous | three runs: 0xC1–0xC9, 0xD1–0xD9, 0xE2–0xE9 |
| Lowercase a–z | 0x61–0x7A, contiguous | three runs: 0x81–0x89, 0x91–0x99, 0xA2–0xA9 |
Payment data is mostly digits and spaces, which makes the rule of thumb very reliable: a screen full of F0–F9 broken up by runs of 0x40 is almost certainly EBCDIC; a screen full of 0x3? with 0x20 in between is ASCII. There is a negative signal too — ASCII text always has the high bit clear, so every byte falls in 0x00–0x7F. Data with lots of bytes above 0x80 is either not ASCII or not text at all.
Card-scheme clearing files such as Mastercard IPM (T112) are EBCDIC-encoded for a plain historical reason: the clearing platforms were built in the mainframe era, and EBCDIC is the native character set of IBM mainframes. The code page simply stayed. Online authorization messages vary by specification (ASCII, BCD and EBCDIC all exist in the wild), but on the batch clearing side EBCDIC is the norm. So before decoding a clearing file as ASCII, drop it into the viewer above and check the EBCDIC column first — the PAN, amounts and merchant names usually become readable immediately. To decode IPM records field by field, use the Mastercard IPM File Parser.
Sometimes both columns show nothing but dots, yet the bytes look suspiciously tidy. That is usually BCD (packed decimal): each byte stores two decimal digits, one per nibble, so 0x01 0x10 holds the value 0110. BCD is not a character encoding — there is no printable character behind it — which is exactly why neither the ASCII nor the EBCDIC column can render it. The giveaway is that every nibble is 9 or less: all bytes fall in 0x00–0x99 with both halves in the 0–9 range. Four digits take 4 bytes in ASCII but only 2 in BCD, which is why many specifications pack the MTI, amounts and dates this way. To convert values between hex, decimal, binary and BCD, use the Hex, Decimal, Binary and BCD Converter.
Take these 8 bytes: F1 F9 F8 F7 40 C9 D7 D4.
| Bytes | As ASCII | As EBCDIC (CP500) |
|---|---|---|
F1 F9 F8 F7 | all above 0x7E — four dots | 0xF1–0xF7 sit in the digit range → 1 9 8 7 |
40 | @ (0x40 is @ in ASCII) | space |
C9 D7 D4 | all above 0x7E — three dots | C9=I, D7=P, D4=M |
The ASCII column comes out as ....@... while the EBCDIC column reads 1987 IPM — gibberish on one side, language on the other, case closed. The same text stored as ASCII would be 31 39 38 37 20 49 50 4D: paste that in and it is the ASCII column's turn to read 1987 IPM. Try both strings in the viewer above and the division of labour between the two columns becomes obvious.