Introduction
If you have ever needed to read a file generated by an IBM mainframe, you have hit the EBCDIC wall. EBCDIC (Extended Binary Coded Decimal Interchange Code) is an 8-bit character encoding used on IBM z/OS, z/VSE, and AS/400 systems that predates ASCII and is fundamentally incompatible with it. The letter 'A' is 0x41 in ASCII but 0xC1 in EBCDIC. This tool converts between ASCII and EBCDIC across four IBM codepages (037, 500, 1047, 285), showing a byte-by-byte conversion table with hex input, hex output, and character representations. Paste text or hex bytes and convert instantly, all in your browser.
What this tool does
- Convert ASCII text to EBCDIC bytes (displayed as hex) using IBM codepage 037, 500, 1047, or 285
- Convert EBCDIC hex bytes back to ASCII text, with support for space-separated or contiguous hex input
- Show a byte-by-byte conversion table with input hex, input character, output hex, output character, and mapping status for every byte
- Display input and output hex side by side, plus byte count and unmapped character count statistics
- Support four IBM codepages: 037 (US English), 500 (International), 1047 (Latin-1/Unix), and 285 (UK English with pound sign)
- Run entirely client-side: input text and converted output never leave your browser
How this tool works
The tool uses hardcoded ASCII-to-EBCDIC mapping tables for each of the four supported codepages. Each table is a 256-entry array where the index is the ASCII byte value and the value is the corresponding EBCDIC byte. The reverse mapping (EBCDIC to ASCII) is computed at runtime by inverting the table.
For ASCII-to-EBCDIC conversion, the tool encodes the input text as UTF-8 bytes, then maps each byte through the selected codepage's table. The output is displayed as space-separated hex bytes because EBCDIC bytes are generally not valid UTF-8 and would render as garbage characters or replacement symbols.
For EBCDIC-to-ASCII conversion, the tool parses the input as hex bytes (accepting both space-separated and contiguous formats, with optional 0x prefixes). Each EBCDIC byte is mapped through the reverse table to its ASCII equivalent. If an EBCDIC byte has no mapping in the selected codepage (which can happen with codepage-specific characters), the tool substitutes 0x3F (question mark) and increments the unmapped counter.
The byte-by-byte table shows every input byte with its hex value, printable character representation (or dot for non-printable bytes), the output hex value, output character, and whether the mapping was successful. This makes it easy to spot unmapped characters and understand exactly how each byte transforms.
The four codepages differ mainly in their handling of national characters. IBM 037 is US English. IBM 500 is the international version. IBM 1047 is used on Unix services running on z/OS and is similar to Latin-1. IBM 285 is UK English, where the pound sign replaces the dollar sign at certain EBCDIC code points.
How EBCDIC and ASCII conversion works
EBCDIC was introduced by IBM in 1964 with the System/360 mainframe. It is an 8-bit encoding derived from earlier punched-card codes (Hollerith encoding), where the layout of holes in an 80-column card determined the character. The IBM EBCDIC specification documents the codepage tables used across different national language versions.
The key difference from ASCII is the byte layout. In ASCII, letters are contiguous (A=0x41, B=0x42, ..., Z=0x5A). In EBCDIC, letters are split into three non-contiguous blocks: A-I at 0xC1-0xC9, J-R at 0xD1-0xD9, and S-Z at 0xE2-0xE9. Digits are at 0xF0-0xF9. This layout reflects the underlying punched-card encoding, where rows were grouped by zone punches (the top three rows of the card) and digit punches (the bottom nine rows).
EBCDIC codepages are identified by CCSID (Coded Character Set Identifier) numbers. The four supported here are among the most common: CCSID 037 (US English, used on most American mainframes), CCSID 500 (international, used in multinational environments), CCSID 1047 (Latin-1, used by Unix System Services on z/OS, documented in Unicode Technical Report 16), and CCSID 285 (UK English, where the pound sign occupies the code point that holds the dollar sign in 037).
Modern mainframes support Unicode (UTF-EBCDIC, or full UTF-16 via the z/OS Unicode support), but EBCDIC remains the native encoding for many legacy applications, batch jobs, and fixed-length record files. When transferring files between mainframe and distributed systems, EBCDIC-to-ASCII conversion is a standard step. Tools like `iconv` on Unix and the `dd` command with `conv=ascii` handle this at the file level. This tool handles it at the interactive, byte-level view that makes the mapping visible.
How to use this tool
- Select a direction: ASCII to EBCDIC (text input, hex output) or EBCDIC to ASCII (hex input, text output)
- Choose a codepage from the dropdown: IBM 037 (US English), 500 (International), 1047 (Latin-1/Unix), or 285 (UK English)
- For ASCII to EBCDIC: type or paste text in the input field. The tool converts each character to its EBCDIC byte equivalent
- For EBCDIC to ASCII: enter space-separated hex bytes (e.g. C1 C2 C3) or contiguous hex (e.g. C1C2C3). The tool converts each EBCDIC byte to its ASCII equivalent
- Review the byte-by-byte conversion table to see input hex, input character, output hex, output character, and mapping status for every byte
- Check the statistics panel for total bytes converted and unmapped character count
Real-world examples
Converting 'Hello' from ASCII to EBCDIC (IBM 037)
Input: `Hello` (5 bytes: 0x48 0x65 0x6C 0x6C 0x6F). Using IBM 037, the mapping is: H (0x48) -> 0xC8, e (0x65) -> 0x85, l (0x6C) -> 0x93, l (0x6C) -> 0x93, o (0x6F) -> 0x96. The EBCDIC output is `C8 85 93 93 96`. The byte-by-byte table shows each character with its ASCII and EBCDIC hex values side by side. Note that lowercase letters map to different EBCDIC ranges (0x81-0x89, 0x91-0x99, 0xA2-0xA9) than uppercase (0xC1-0xC9, 0xD1-0xD9, 0xE2-0xE9).
Converting EBCDIC hex back to ASCII
Input: `C1 C2 C3` (3 EBCDIC bytes). Using IBM 037, 0xC1 maps to 'A', 0xC2 maps to 'B', 0xC3 maps to 'C'. The ASCII output is `ABC`. This is the reverse of the first example. The tool accepts both space-separated hex (`C1 C2 C3`) and contiguous hex (`C1C2C3`), and also handles 0x prefixes (`0xC1 0xC2 0xC3`).
Codepage differences: IBM 037 vs IBM 285
The main difference between IBM 037 (US English) and IBM 285 (UK English) is the pound sign. In 037, EBCDIC 0x5B maps to ASCII '$' (dollar). In 285, EBCDIC 0x4A maps to the UK pound sign. If you convert the text 'price is £5' using codepage 285, the pound sign maps correctly. If you use codepage 037, the pound sign may be unmapped (showing as '?') because 037 does not include it at the same code point.
Handling unmapped EBCDIC bytes
When converting EBCDIC to ASCII, some EBCDIC byte values may not have a mapping in the selected codepage. For example, certain control characters or codepage-specific symbols. The tool substitutes 0x3F (question mark) for unmapped bytes and increments the unmapped counter. The byte-by-byte table marks these rows with 'unmapped' in red, so you can identify exactly which bytes failed to convert.
Converting a mainframe record with mixed content
Input (EBCDIC hex): `F0F1F2F340D5C1D4C540D7E2C5` using IBM 037. The tool decodes: F0-F3 = '0123', 0x40 = space, D5='N', C1='A', D4='M', C5='E', 0x40 = space, D7='P', E2='S', C5='E'. The ASCII output is `0123 NAME PSE`. The hex display shows both input and output hex side by side, and the byte-by-byte table confirms each mapping. This is typical of fixed-length mainframe records where fields are padded with spaces (EBCDIC 0x40).
Comparison with similar methods
| Method | Complexity | Typical use |
|---|---|---|
| IBM 037 | US English EBCDIC, 256-entry lookup table | American mainframe systems, z/OS default |
| IBM 500 | International EBCDIC, 256-entry lookup table | Multinational mainframe environments |
| IBM 1047 | Latin-1/Unix EBCDIC, 256-entry lookup table | Unix System Services on z/OS |
| IBM 285 | UK English EBCDIC, pound sign variant | UK mainframe systems |
| ASCII (ISO 8859-1) | 8-bit Western European, no conversion needed | Modern systems, web, Unix, Windows |
Limitations or considerations
EBCDIC conversion is a character mapping, not an encoding or encryption. It changes byte values to represent the same characters in a different encoding scheme. No data is hidden or protected.
This tool supports four of the most common EBCDIC codepages. IBM defines dozens of additional codepages for other languages (Japanese, Korean, Arabic, etc.) that use multi-byte or different single-byte mappings. Those are not supported here.
The tool processes input as Latin-1 / single-byte characters for the ASCII side. Multi-byte UTF-8 characters (like emoji or CJK characters) will be converted byte-by-byte, which will not produce meaningful EBCDIC output. For mainframe text, the input is typically ASCII or Latin-1 range (0x00-0xFF).
Some EBCDIC code points have no ASCII equivalent in a given codepage, particularly control characters and codepage-specific symbols. The tool substitutes 0x3F (question mark) for these. The unmapped counter in the statistics panel tells you how many bytes fell into this category.
For file-level conversion of large mainframe datasets, use `iconv` or a dedicated EBCDIC conversion utility. This tool is designed for interactive, byte-level inspection. For related encoding tools, see Base64 Encode/Decode, Hex Encode/Decode, and Binary to Text.
Frequently asked questions
What is EBCDIC and how does it differ from ASCII?
EBCDIC (Extended Binary Coded Decimal Interchange Code) is an 8-bit character encoding introduced by IBM in 1964 for the System/360. The main difference from ASCII is the byte layout: in ASCII, letters are contiguous (A=0x41, B=0x42), but in EBCDIC they are split into three non-contiguous blocks (A-I at 0xC1-0xC9, J-R at 0xD1-0xD9, S-Z at 0xE2-0xE9). This layout comes from punched-card encoding where characters were grouped by zone punches.
Which IBM codepages does this tool support?
The tool supports four codepages: IBM 037 (US English, the most common mainframe codepage), IBM 500 (International), IBM 1047 (Latin-1/Unix, used by Unix System Services on z/OS), and IBM 285 (UK English, which includes the pound sign). IBM defines many additional codepages for other languages, but these four cover the most common Western-language mainframe environments.
Why is the EBCDIC output shown as hex instead of text?
EBCDIC bytes are generally not valid UTF-8, so displaying them as text would produce garbage characters or Unicode replacement symbols. Showing the output as hex bytes (e.g. C8 85 93 93 96) makes the actual byte values visible and unambiguous. The byte-by-byte table shows the printable ASCII character representation alongside the hex values for reference.
What does the 'unmapped characters' counter mean?
When converting EBCDIC to ASCII, some EBCDIC byte values may not have a mapping in the selected codepage. This happens with control characters, codepage-specific symbols, or bytes that are valid in one codepage but not another. The tool substitutes 0x3F (question mark) for unmapped bytes and counts them. A non-zero count means some bytes could not be converted accurately.
Is EBCDIC still used today?
Yes. EBCDIC remains the native encoding for IBM z/OS mainframes, which process a significant portion of the world's banking, insurance, and government transactions. While modern mainframes also support Unicode, many legacy applications, batch jobs, and fixed-length record files still use EBCDIC. Conversion between EBCDIC and ASCII is a routine step when integrating mainframe and distributed systems.
How do I convert a whole file from EBCDIC to ASCII?
For file-level conversion, use the `iconv` command on Unix or Linux: `iconv -f IBM037 -t ISO-8859-1 input.bin > output.txt`. On z/OS, the `dd` command with `conv=ascii` performs the conversion. This tool is designed for interactive, byte-level inspection rather than batch file processing.
Conclusion
EBCDIC is a living encoding: it runs behind the scenes in banking, insurance, and government systems worldwide on IBM mainframes. Converting between EBCDIC and ASCII is a routine task when integrating mainframe data with modern systems. This tool makes the byte-level mapping visible across four common codepages, with a per-byte table that shows exactly how each character transforms. For related encoding tools, see Base64 Encode/Decode, Hex Encode/Decode, and Binary to Text.