ISO 8583 Message Decoder

How a message is put together

An ISO 8583 message has no delimiters and no field names. It is an MTI, then a bitmap saying which data elements are present, then those elements back to back in numerical order. The receiver knows where each one ends because it already holds the field definitions. That is why a message is unreadable without them, and why a single wrong length throws off everything that follows.

This tool walks that structure: MTI, bitmap, then each field in turn, recording where every element starts and stops. Hover a row and the hex view shows you which bytes it came from.

Why your message will not parse

Almost always the encoding, and almost always the length prefixes. The same logical message can sit on the wire two entirely different ways, and nothing in the message says which:

In an ASCII implementation every position is one byte. The MTI 0100 is four bytes, 30 31 30 30. The bitmap arrives as sixteen hex characters. A 2-digit LLVAR prefix is two bytes.

In a packed implementation numeric fields are BCD, two digits to a byte. The same MTI is two bytes, 01 00. The bitmap is eight raw bytes. That 2-digit prefix is one byte.

And the two vary independently: plenty of otherwise-ASCII hosts send BCD length prefixes. So both are toggles here rather than assumptions. If the first few fields look right and then everything after a point turns to noise, the cursor slipped at a length prefix, so switch that setting before you suspect anything else. The Work out the encoding button tries the combinations and tells you which ones read the message to the end.

The one that does not break the walk

Character set is a third axis, and it behaves unlike the other two. Mainframe acquirers send EBCDIC, code page 037, where C is C3 rather than 43. Because EBCDIC and ASCII are both one byte per character, getting this wrong moves no field boundary at all: the bitmap reads, every length prefix reads, every offset is correct, and only the merchant name and terminal id come out as rubbish.

That makes it the only encoding mistake here that produces a clean-looking decode with wrong values in it, which is why it is not left to the Work out the encoding button. No score based on "did this parse" could tell the two apart, since both parse identically. Instead each text field is checked against both readings, and if the other one is clearly the sensible one the field says so and quotes it. The commonest shape is packed BCD numerics with EBCDIC text, so the character set is its own setting rather than being tied to the field encoding.

What it will not do

It will not guess. If a field is present in the bitmap but has no definition, the walk stops there and says so, rather than skipping ahead to where the next field probably starts. A confident wrong answer is worse than a located failure, because you act on it.

It will not interpret the private-use fields, 48, 60 to 63, 120 to 127. Those mean whatever your processor decided they mean, and no standard covers them. You get the raw bytes, which is the honest answer. Same for anything cryptographic: no ARQC verification, no PIN block decryption, no MAC checking. Those need keys, and this page has none and wants none.

Base ISO 8583 only. Scheme dialects redefine plenty of fields, and claiming to support one without the specification behind it would produce the confident nonsense the rest of this page avoids.

Where to go next

Each decoded element links to the tool that specialises in it. DE 55 opens in the TLV parser, a TVR in the bit field decoder, and a TVR with bits set will offer the IAC comparator, which explains which bit forced the decline. DE 22 goes to POS entry mode, DE 35 to the track parser, DE 2 to the PAN validator.

The checks

The warnings compare things the message states against each other: a track carrying a different PAN from DE 2, an entry mode claiming chip with no DE 55 behind it, an approval with no authorisation code, an amount with no currency to give it decimal places. None of them block the decode, and a warning is not proof of a bug. A zero-amount purchase is an account verification when it is meant to be one.

Your data

The message never leaves the page. There is no backend to send it to, and the content security policy stops the browser sending anything to another host: connect-src 'none' blocks every connection a script could open, and default-src 'self' blocks the ways around it. You can check both in devtools. Cardholder fields are masked by default, which is about screen shares and screenshots rather than security.