EBCDIC is the character encoding the rest of the computing world left behind, but mainframes never did. This converter translates between ASCII text and IBM EBCDIC code page 037 in both directions, byte by byte.
Where EBCDIC comes from and why it still exists
EBCDIC (Extended Binary Coded Decimal Interchange Code) originated at IBM in the 1960s as an extension of 6-bit punch-card codes to 8 bits. When IBM designed its System/360 mainframe in 1964, EBCDIC became the default character encoding — and because IBM mainframes were widely deployed in banking, insurance, healthcare, and government, that encoding became deeply embedded in legacy data systems.
Unlike ASCII (which was also standardised in the 1960s but adopted by almost every other computing platform), EBCDIC survived because replacing it on mainframes carrying decades of mission-critical data and software is extremely costly. A bank processing millions of transactions a day on a z/OS mainframe does not lightly migrate its character encoding. As a result, EBCDIC remains in active daily use in the 2020s, primarily on IBM z/OS (formerly OS/390) and IBM i (formerly AS/400) systems.
Why EBCDIC is not just a shifted ASCII
The most confusing thing about EBCDIC for developers who have only worked in ASCII environments is that the two character sets share many characters but map them to completely different byte values, and in a completely different order. In ASCII, the letter A is 0x41 and Z is 0x5A — 26 contiguous bytes. In CP037 (EBCDIC US English), A is 0xC1 and Z is 0xE9, but the letters are distributed across three non-contiguous ranges (0xC1–0xC9, 0xD1–0xD9, 0xE2–0xE9) with gaps in between.
This means you cannot do arithmetic on EBCDIC bytes to step through the alphabet, you cannot compare ASCII and EBCDIC bytes numerically, and a file written by a mainframe in EBCDIC looks like garbage when read by a PC expecting ASCII or UTF-8. You need a lookup table — which is exactly what this tool provides.
How it works
EBCDIC maps each character to a single 8-bit value, but the layout is nothing like ASCII. Encoding looks each ASCII character up in the CP037 table and emits its EBCDIC byte in hex; decoding reverses the lookup:
text → CP037 table → EBCDIC hex bytes
hex → reverse CP037 → ASCII textThe critical gotcha is that letters are not contiguous. In CP037 the letters A to I, J to R, and S to Z sit in separate blocks with gaps between them, so incrementing a byte does not move to the next letter as it would in ASCII.
Tips and notes
- Always confirm the code page. CP037 is the US English variant; other countries use different EBCDIC pages that map punctuation differently.
- When decoding, separate bytes with spaces or commas, for example
C8 85 93 93 96. - Never assume alphabetical arithmetic on EBCDIC bytes — use the table, which is exactly what this tool does.
Common real-world EBCDIC integration scenarios
Fixed-width flat files from a mainframe: z/OS batch jobs often write data as fixed-width records in EBCDIC. To read them in a modern system, transfer the file in binary mode (not text mode — text mode on some FTP clients “translates” EBCDIC to ASCII during transfer, which may or may not be what you want) and then apply the correct code page translation.
MQ messages from IBM MQ: IBM MQ message queues running on z/OS often carry EBCDIC-encoded character data. The message header includes a CCSID (Coded Character Set Identifier) field that tells the reader which code page was used. CP037 corresponds to CCSID 37.
JCL and job output: JES spool files and JCL job control language are stored in EBCDIC. When screen-scraping or automating a mainframe session via a terminal emulator or 3270 API, the emulator handles translation — but if you are reading raw output from a file capture, you will need to decode it.
Cobol COMP-3 (packed decimal) fields: Mainframe COBOL programs often store numeric fields in packed decimal format alongside EBCDIC character fields. The packed decimal fields are binary, not EBCDIC, so they need separate handling — translating them through the EBCDIC table would corrupt them. Identify field types from the COBOL copybook before applying any encoding conversion.