ASCII World

ASCII to EBCDIC Converter

EBCDIC (IBM Code Page 037) assigns completely different numeric values to every character compared to ASCII. The letter A is 65 in ASCII but 193 (0xC1) in EBCDIC. Digits 0-9 sit at positions 240-249 instead of 48-57. This tool converts between the two encodings and shows the character-by-character mapping.

Use it when migrating data off IBM mainframes (z/OS, AS/400), debugging FTP file transfers that arrive as garbled text, or parsing COBOL copybook layouts where field values are stored in EBCDIC.

How the Mapping Works

IBM created EBCDIC in 1963 to match the punch card encoding used by its System/360 mainframes. Each punch card column encoded a character using a combination of zone punches (rows 12, 11, 0) and digit punches (rows 1-9). EBCDIC preserved this structure in binary: the high nibble represents the zone and the low nibble represents the digit. ASCII, designed by a different committee the same year, arranged characters for teletype simplicity instead.

The result is that letters in EBCDIC are split across three non-contiguous ranges. A-I occupy 0xC1-0xC9, J-R occupy 0xD1-0xD9, and S-Z occupy 0xE2-0xE9. There are gaps between each group. In ASCII, A-Z is one unbroken run from 65 to 90. This means you cannot check if an EBCDIC byte is a letter with a simple range comparison the way you can in ASCII. You need a lookup table or multiple range checks.

Common Conversion Scenarios

Mainframe data migration. When moving datasets from z/OS to Linux or cloud storage, text fields stored in EBCDIC must be converted to ASCII or UTF-8. Tools like IBM's DFDSS and third-party ETL platforms handle this at scale. For spot-checking individual records, this converter shows you exactly what each byte maps to.

FTP transfer issues. Transferring files between a mainframe and a Unix system in ASCII mode triggers automatic EBCDIC-to-ASCII conversion by the FTP server. If you accidentally transfer in binary mode, the file arrives with raw EBCDIC bytes that look like garbage in a text editor. Paste the hex dump into this converter to verify the original content.

COBOL copybook parsing. COBOL applications on IBM mainframes store data in fixed-width records using EBCDIC. When reading these records from a flat file on a modern system, each byte needs EBCDIC-to-ASCII translation before the field values make sense. Packed decimal (COMP-3) fields are separate - those are numeric encodings, not character data.

JCL and SPOOL output. Job Control Language output and SPOOL files from batch jobs are EBCDIC text. Downloading them via FTP in ASCII mode converts automatically, but if you capture raw SPOOL data through an API or direct dataset read, you get EBCDIC bytes that need conversion before they are readable.

Frequently Asked Questions

Why are EBCDIC letter codes split into three separate ranges?
IBM derived EBCDIC from Binary Coded Decimal (BCD) punch card encoding. Each card column had a zone punch (12, 11, or 0) plus a digit punch (1-9). The zone punch determined which of three letter groups a character fell into: A-I mapped to zone 12 (EBCDIC 0xC1-0xC9), J-R to zone 11 (0xD1-0xD9), and S-Z to zone 0 (0xE2-0xE9). This made EBCDIC natural for punch card hardware but created the non-contiguous layout that complicates sorting and range checks compared to ASCII.
Can I convert EBCDIC files on a modern computer without mainframe access?
Yes. On Linux and macOS, use iconv: iconv -f EBCDIC-US -t ASCII input.dat > output.txt. In Python, open the file with codecs or specify encoding="cp037" in the open() call. The dd command with conv=ascii also works on some Unix systems. For batch file conversion during mainframe migrations, most ETL tools (Informatica, Talend, Apache NiFi) have built-in EBCDIC code page support.
Which EBCDIC code page should I use?
CP037 (US/Canada English) is the most common and is what this converter uses. CP500 (International Latin-1) is identical for letters and digits but differs in bracket and brace positions. CP1047 is the code page used by z/OS Unix System Services and swaps the newline character from 0x15 (CP037) to 0x25. If you are converting mainframe COBOL data, check the CODEPAGE parameter in the JCL or the EBCDIC CCSID in DB2 catalog tables to confirm which variant your source uses.