Drop a Mastercard IPM clearing file — the T112 — on this page and read it as named fields instead of raw hex. 1014-byte deblocking, VBS record framing and EBCDIC decoding are handled automatically, and PDS subfields are expanded for you.
Parsing runs entirely in this browser tab, in client-side JavaScript. The page has no upload endpoint — open your browser's developer tools and watch the network panel while you parse: no request carries your file. It works exactly the same with the network switched off.
That is deliberate, not a footnote. An IPM file is never test data — every record in it is a real card number and a real transaction — which is why a parser that requires uploading clearing files is a parser most issuers and processors are not allowed to use.
If auto-detect gets it wrong, set the encoding and file format manually with the two dropdowns above.
An IPM clearing file is three layers stacked on top of each other, and each one trips people up in a different way. None of the three is arbitrary — each is a fossil of where this format grew up.
1014-byte blocking
Records are packed into 1014-byte blocks: 1012 bytes of payload followed by two pad bytes. The number stops looking arbitrary once you notice what the pad usually is: 0x40, the EBCDIC space. Blocking is a mainframe file-transfer convention — fixed-size physical blocks made tape and dataset I/O predictable — and it survived because both endpoints of clearing were mainframes for decades. Strip the padding before anything else, or every record after the first block is misaligned.
VBS record framing
Inside the unblocked stream each record is preceded by a 4-byte big-endian length; a length of zero ends the file. There are no separators and no newlines, so nothing re-synchronises you: get one length wrong and every record boundary after it drifts silently.
EBCDIC text
Text fields are EBCDIC, not ASCII — digits sit at 0xF0–0xF9 instead of 0x30–0x39. It persists for the same reason the blocking does: clearing is a batch pipeline between systems that agreed on an encoding long ago, and batch formats only change when something forces them to. ASCII variants do exist, so this tool reads the MTI bytes of the first record and decides from those.
An IPM record carries two different kinds of fields. Data elements are the ISO 8583 layer: numbered 1–128, presence decided by the bitmap, each with a fixed type and length rule. That layout is compact but rigid — 128 positional slots were never going to hold everything clearing needs to say about a transaction.
So a handful of data elements (48, 62, 123–125) act as carriers for PDS — Private Data Subelements. A PDS entry is self-describing: a 4-digit tag, a 3-digit length, then the value, repeated until the carrier field is exhausted. Because each entry names itself, new tags can ship without touching the bitmap layout — which is exactly why so much of the commercially interesting data (fees, indicators, programme identifiers) lives there rather than in a numbered DE.
This tool unrolls the carrier DEs and lists every PDS tag as its own row. The values are shown raw: their internal layouts are Mastercard's own documentation, and this page interprets only the publicly documented layer.
Before reading any field value, confirm the frame — most "corrupt file" reports are framing problems, not data problems.
Encoding. The first record's MTI bytes (right after the 4-byte length prefix) settle it: F1 F6 F4 F4 is "1644" in EBCDIC, 31 36 34 34 is the same in ASCII.
Envelope records. A well-formed file opens with an MTI 1644 file-header record and closes with a 1644 file trailer; the transactions in between are 1240 detail records. A file that starts mid-stream or ends without a trailer was truncated somewhere along the way.
If boundaries look wrong. Absurd record lengths or misaligned fields usually mean wrong deblocking, or a file that was re-encoded in transit — FTP in text mode quietly rewriting bytes is the classic. Fix the transport before blaming the fields.
Each record starts with a 4-character MTI and a 16-byte bitmap covering data elements 1–128; the bitmap decides which fields are present, so positions are never fixed. The output gives you a business view first — amounts converted by each currency's exponent, PAN masked by default — with the full technical field table, per-record JSON and the raw hex underneath, so one file works for both the settlement analyst and the integration engineer.
Every tool that touches IPM files has to answer one question before any feature matters: where does the file go? A clearing file is the day's card transactions with nothing anonymised — under PCI DSS, the PANs alone already make it cardholder data.
That is the whole design constraint behind this parser. The file is read with the browser's FileReader API and never enters a network request — and you don't have to take that on trust, because the network panel of your own developer tools will show you.
It reads IPM-format transaction files — in practice the T112. It does not read Mastercard's report files, which are a different format entirely: T140 is a GCMS reconciliation report and TQR4 is a Mastercom reconciliation report, neither of which contains ISO 8583 records. IPM parameter extract files (IP0000T1 and friends) are also out of scope — same envelope, different record layout.
It carries the publicly documented IPM data-element layout only. PDS values are shown as raw text and EMV/ICC data as raw TLV hex — no scheme-private subfield names are interpreted. Visa clearing files are a different format and are not covered by this tool.
Field definitions and parsing rules follow cardutil by Anthony Delosa, MIT licensed. This page is an independent browser implementation of the same public rules.