About

EBCDIC (Extended Binary Coded Decimal Interchange Code) is an 8-bit character encoding used primarily on IBM mainframe and midrange systems. Unlike ASCII, which dominates modern computing, EBCDIC arranges letters non-contiguously: A - I occupy positions 0xC1 - 0xC9, J - R sit at 0xD1 - 0xD9, and S - Z at 0xE2 - 0xE9. A single misinterpreted byte during mainframe data migration can corrupt entire records in COBOL copybooks, JCL streams, or VSAM datasets. This tool implements IBM Code Page 037 (CP037), the most common EBCDIC variant used in US/Canada/Europe Latin-1 environments.

The converter accepts raw binary strings in 8-bit groups and maps each octet to its CP037 character representation. It also operates in reverse: given EBCDIC-printable text, it produces the corresponding binary sequence. Note that control characters (positions 0x00 - 0x3F) have no printable glyph and are rendered as placeholders. This tool does not handle DBCS (Double-Byte Character Set) extensions or code page 500/1047 variants.

Formulas

Binary to EBCDIC conversion is a direct lookup operation. Each group of 8 binary digits represents one byte in the range 0 - 255. That byte is used as an index into the IBM Code Page 037 character table.

decimal = 7∑i=0 b_i × 2^{7 − i}

Where b_i is the i-th bit (left to right, 0-indexed) of the 8-bit binary string. The resulting decimal value is then mapped:

char = CP037[decimal]

For the reverse direction (text to binary), each character c is located in the CP037 table to find its index idx, then converted back to an 8-bit binary string by computing each bit position. Characters not present in CP037 are flagged as unmappable. The hexadecimal representation is derived by grouping each 4-bit nibble: the high nibble = floor(decimal ÷ 16) and the low nibble = decimal mod 16.

Reference Data

Character	EBCDIC Hex (CP037)	EBCDIC Decimal	Binary	ASCII Hex
Space	0x40	64	01000000	0x20
0	0xF0	240	11110000	0x30
1	0xF1	241	11110001	0x31
2	0xF2	242	11110010	0x32
3	0xF3	243	11110011	0x33
4	0xF4	244	11110100	0x34
5	0xF5	245	11110101	0x35
6	0xF6	246	11110110	0x36
7	0xF7	247	11110111	0x37
8	0xF8	248	11111000	0x38
9	0xF9	249	11111001	0x39
A	0xC1	193	11000001	0x41
B	0xC2	194	11000010	0x42
C	0xC3	195	11000011	0x43
D	0xC4	196	11000100	0x44
E	0xC5	197	11000101	0x45
F	0xC6	198	11000110	0x46
G	0xC7	199	11000111	0x47
H	0xC8	200	11001000	0x48
I	0xC9	201	11001001	0x49
J	0xD1	209	11010001	0x4A
K	0xD2	210	11010010	0x4B
L	0xD3	211	11010011	0x4C
M	0xD4	212	11010100	0x4D
N	0xD5	213	11010101	0x4E
O	0xD6	214	11010110	0x4F
P	0xD7	215	11010111	0x50
Q	0xD8	216	11011000	0x51
R	0xD9	217	11011001	0x52
S	0xE2	226	11100010	0x53
T	0xE3	227	11100011	0x54
U	0xE4	228	11100100	0x55
V	0xE5	229	11100101	0x56
W	0xE6	230	11100110	0x57
X	0xE7	231	11100111	0x58
Y	0xE8	232	11101000	0x59
Z	0xE9	233	11101001	0x5A

Frequently Asked Questions

Both are EBCDIC variants, but they differ in the placement of certain special characters. CP037 is the standard for US, Canada, Netherlands, Portugal, and Brazil. CP500 (International Latin-1) swaps the positions of characters like the exclamation mark (0x5A in CP037 vs 0x4F in CP500) and square brackets. If you are working with international IBM mainframe data from Western Europe, verify which code page was used during data creation. Using the wrong page will silently corrupt special characters while leaving letters and digits intact.

EBCDIC evolved from punched card encoding used on IBM System/360 in 1964. Punched cards used a zone-digit scheme: letters A - I use zone 12 (hex 0xC_), J - R use zone 11 (hex 0xD_), and S - Z use zone 0 (hex 0xE_). This creates gaps in the code point sequence. Practically, this means simple range checks like c ≥ 0xC1 ∧ c ≤ 0xE9 will incorrectly include non-letter characters that fall in the gaps (0xCA - 0xD0 and 0xDA - 0xE1).

EBCDIC positions 0x00 - 0x3F are mostly control characters (NUL, SOH, STX, etc.). This converter displays them as a dot placeholder (·) since they have no visual glyph. In mainframe file transfers, these bytes often appear in packed decimal fields or binary data embedded within text records. If your binary input decodes to many control characters, the source data is likely not text but rather COMP-3 packed fields or binary integers, which require numeric unpacking rather than character conversion.

Yes, but indirectly. First enter your text in the EBCDIC-to-Binary direction. The tool maps each character to its CP037 position. However, be aware that not every Unicode or ASCII character has a CP037 equivalent. Characters like curly braces, backslash, and tilde occupy different positions in EBCDIC than in ASCII. The tool will flag unmappable characters. For production file transfers between ASCII and EBCDIC systems, always verify the mapping with a hex dump of a known test record.

EBCDIC is strictly an 8-bit encoding. Each character requires exactly 8 bits. If your input has, for example, 13 bits after stripping whitespace, the tool will reject it and report the remainder. The most common cause is a truncated copy-paste. Verify your source data is complete. Some mainframe dump tools insert line breaks or headers that must be removed before conversion.

No. EBCDIC is a single-byte encoding, so endianness is irrelevant for character data. Endianness only matters for multi-byte numeric fields (halfword, fullword, doubleword) stored on mainframes, which use big-endian byte order. If you are converting binary representations of COMP or COMP-4 fields, you need a numeric converter, not a character converter.