Parse ISO 8583 messages: MTI, bitmap, 128 data elements, DE55 EMV-TLV tag decode. ASCII / Hex(BCD) / EBCDIC.
The tools above tell you what a value is. These go into why the field works the way it does, where the card schemes disagree with each other, and which rules survive contact with a real production log. Forty-odd pieces, written from working with these messages rather than paraphrased from a spec — the full list is here.
Every ISO 8583 message has the same three-layer shape: a four-digit MTI (Message Type Indicator) that says what kind of message it is, one or two 64-bit bitmaps that say which fields are present, and the data elements themselves, laid out one after another in field-number order. The parser above splits those layers apart for you; knowing how they fit together tells you which parts of the output to trust — and where to look when something is off.
Read the MTI digit by digit: version, class, function, origin. 0100 is an authorization request and 0110 its response; 0200 is a financial request, 0400 a reversal, 0800 network management (sign-on, echo test). After the bitmap, the data elements appear in ascending order. Each element has a format — numeric, alphanumeric or binary — and is either fixed-length or variable-length with a 2- or 3-digit length prefix (LLVAR / LLLVAR). The walkthrough in Reading ISO 8583: MTI, bitmaps & fields covers this layer by layer, and the complete list of all 128 data elements gives every field its name, format and meaning. One trap worth knowing early: amounts such as DE4 are integers in the currency's minor units — 000000001000 is 10.00 in USD but 1000 in JPY — see why amounts have no decimal point.
Bit 1 of the primary bitmap is special: it does not describe a data field, it announces that a secondary bitmap for fields 65–128 follows immediately after the primary one. Quick check: if the first hex character of the bitmap is 8 or higher, bit 1 is set and the bitmap runs 32 hex characters instead of 16. Misjudge this one bit and every field after the bitmap shifts. You can build or decode bitmaps by hand with the bitmap calculator.
The bytes on the wire carry no encoding label — the same bytes mean different things depending on the convention used to read them. In ASCII, each character is one byte: the MTI 0200 is 30 32 30 30. In packed BCD, two digits share one byte: the same MTI is just 02 00. In EBCDIC — the IBM mainframe character set still used on some scheme interfaces — the digit 0 is F0, so 0200 becomes F0 F2 F0 F0. Feed EBCDIC bytes to an ASCII decoder and you get gibberish; treat ASCII text as BCD and every field boundary lands in the wrong place. Real messages often mix conventions in a single message: numeric fields in BCD, text fields in EBCDIC, DE55 as binary TLV. The hex viewer shows the same bytes side by side as ASCII and EBCDIC, and the hex / BCD converter handles the digit-level conversions.
Also note that authorization messages and clearing files are two different worlds: Mastercard clearing travels in IPM files, based on ISO 8583:1993, which the separate IPM file parser handles.
The parser reads the message out of the URL, so any link shaped like
https://iso8583parser.com/?m=YOUR_MESSAGE opens with that message already
decoded, field by field. Replace YOUR_MESSAGE with your raw ISO 8583 message —
ASCII or hex, both are accepted — and percent-encode = as %3D.
Decoding runs entirely in your browser: the message is never uploaded, there is no account, and nothing is logged. That makes such a link safe to build for a message you are debugging and safe to send to a colleague.
A code table can be quoted from memory; your message cannot. Anything that depends on the bytes you actually have — which fields the bitmap marks present, how the length prefixes fall, what the DE55 TLV tree contains — needs the message itself in front of it. That is what this URL is for.
ISO 8583 is the international standard for the messages that carry card transactions between terminals, acquirers, card networks and issuers. Every message is built from three layers: a four-digit MTI describing the message type, one or two bitmaps listing which fields are present, and up to 128 data elements carrying the actual values. The 1987 edition is still the basis of most authorization traffic at Visa, Mastercard and other networks.
The primary bitmap is 64 bits — 16 hex characters — and bit N set to 1 means data element N is present in the message. If bit 1 is set (first hex character 8 or higher), a secondary bitmap for fields 65–128 follows immediately, doubling the bitmap to 32 hex characters. Expand the hex into binary, note the positions of the 1-bits, and you have the exact list of fields to read, in order.
Each digit has a fixed role: version (0 = ISO 8583:1987), class (1 = authorization, 2 = financial, 4 = reversal, 8 = network management), function (0 = request, 1 = response, 2 = advice) and origin (who initiated the message). So 0100 is an authorization request and 0110 is its response; 0200 and 0210 are a financial request and its response, and 0400 is a reversal.
Yes — parsing runs entirely in your browser using local JavaScript. The message is never uploaded to any server, nothing is stored, and no account or sign-up is required. If you are working with real production data, it is still good practice to mask the PAN before sharing parsed output with anyone.
Because raw bytes carry no encoding label — the parser has to be told how to interpret them. The digits 0200 are 30 32 30 30 in ASCII, 02 00 in packed BCD and F0 F2 F0 F0 in EBCDIC, so reading with the wrong convention misplaces every field boundary that follows. Real scheme messages often mix encodings in one message: numeric fields in BCD, text in EBCDIC and DE55 as binary TLV.
Both build their authorization messages on ISO 8583, but they are not interchangeable. They differ in message headers, in encoding conventions and in the layout of private fields — Mastercard's DE48, for example, is subdivided into PDS tags. On the clearing side the gap is wider still: Mastercard clearing uses the separate IPM format, based on ISO 8583:1993, rather than the authorization layout.
Card schemes/fields you want supported, parsing issues, or feature ideas — leave a note, we'll review it soon.