Text to EBCDIC Hex Converter

Text to EBCDIC Hex Converter. Type your text into Text Input and the Text to EBCDIC Hex Converter instantly returns its EBCDIC Hex Output. Designers pulling colors from a style guide can drop the hex code into the hex to rgb converter to get matching RGB values.

Need to see exactly which bytes an IBM system stores for your words? This text to EBCDIC hex converter turns plain text into hexadecimal pairs using the EBCDIC character set, so legacy mainframe fields, test records and 8-bit data are easy to read and check. Type or paste your text, pick a code page, click the convert button, and copy the hex output.

How a Text to EBCDIC Hex Converter Works

EBCDIC (Extended Binary Coded Decimal Interchange Code) is an 8-bit character encoding that IBM designed in the 1960s, growing out of the BCD codes used on punch cards. Every character you type occupies exactly one byte, and that byte has one of 256 possible values. An EBCDIC encoder looks each character up in a table and writes the matching byte as two hex digits. Because the table is not the same as the ASCII table, the same letter produces a different byte on a mainframe than on a laptop. Use the hex to hsv converter when a design tool or filter needs an HSV breakdown instead of a raw hex code.

The lookup is not arithmetic across the whole alphabet, but inside each block of letters and numbers the pattern is regular. Digits follow a simple offset, which you can write as a formula:

$$\text{byte}_{\text{EBCDIC}}(d) = \text{F0}_{16} + d \qquad (0 \le d \le 9)$$

So the digit 4 becomes F4, and the digit 9 becomes F9. Uppercase letters are split into three runs: A to I sit at C1 to C9, J to R at D1 to D9, and S to Z at E2 to E9. Lowercase letters follow the same shape starting at 81, 91 and A2. The gaps inside the alphabet are why a simple "add a constant" shortcut never works and a real lookup table is needed.

From text to hexadecimal values in three steps

Paste or type the text you want to encode into the input box, including any spaces, because a space is a real character with its own byte.
Choose the code page that matches your target system, such as CP037 for North America.
Click the convert button and copy the space-separated hex string from the output.

Why the byte values differ from ASCII

ASCII is a 7-bit table with letters in one continuous run, while EBCDIC keeps the zone-and-digit layout of punch cards. Characters such as the letter A sit at 41 in ASCII but at C1 in EBCDIC, and a space moves from 20 to 40. This is the interoperability problem that every data migration between a mainframe and an open system has to solve.

Convert EBCDIC Text to Hex: A Worked Example

Take the string PAY 0412 OK, which might be a status field in a fixed-width record. It holds eleven characters, so the output is eleven bytes, or 22 hex digits. Looking up each character in CP037 gives the table below, with the ASCII hex shown beside it for comparison. The hex to tailwind converter matches a hex color to its closest equivalent in Tailwind's public color palette.

Convert EBCDIC Text to Hex: A Worked Example
Character	ASCII hex	EBCDIC hex (CP037)
P	50	D7
A	41	C1
Y	59	E8
Space	20	40
0	30	F0
4	34	F4
1	31	F1
2	32	F2
Space	20	40
O	4F	D6
K	4B	D2

Joined together, the EBCDIC string becomes D7 C1 E8 40 F0 F4 F1 F2 40 D6 D2, while the same text in ASCII is 50 41 59 20 30 34 31 32 20 4F 4B. Not a single byte matches, which is exactly the situation where a dedicated tool saves you from reading a hex dump by hand.

Reading the hex output

Each pair of hex digits is one byte, so a hex string of 22 digits always means 11 characters. If you see an odd number of digits, a character was cut off. Keep the pairs separated by spaces when you plan to feed them into a hex to EBCDIC converter later, because many tools only accept well formed input in pairs.

Choosing the Right EBCDIC Code Page

A code page is the specific mapping table a system uses, and EBCDIC has many of them. Letters and digits are identical in nearly all variants, but punctuation and national characters move around. Picking the wrong EBCDIC code page is the most common reason converted data looks almost right but contains a wrong bracket or currency symbol.

Choosing the Right EBCDIC Code Page
Code page	Typical use
CP037	US and Canada, the default on most z/OS systems in North America
CP500	International, Western Europe
CP1047	Open systems and Unix System Services on the mainframe
CP285	United Kingdom
CP284	Spain and Latin America

Symbols that change between variants

The table below shows how a few special characters differ between CP037 and CP500, with ASCII for reference. Letters and numbers never move, but the characters used in scripts and file names often do.

Symbols that change between variants
Symbol	ASCII	CP037	CP500
[	5B	BA	4A
]	5D	BB	5A
!	21	5A	4F
\|	7C	4F	BB
^	5E	B0	5F
$	24	5B	5B

Notice that the exclamation mark and the vertical bar swap places between the two variants. If a file from a CICS or IMS region shows odd punctuation after conversion, the code page is the first thing to check.

Where an EBCDIC Converter Helps

An online converter like this one is useful anywhere text crosses between IBM and open platforms. Mainframe developers use it to build test records for COBOL programs, system administrators use it to confirm what a job actually wrote, and data analysts use it to understand a file before loading it into a modern database.

Data migration: confirm exact byte values before moving legacy files to a Unix, Windows or cloud system.
Debugging: compare a hex dump from an AS400 or z/OS job with what your program was supposed to send.
Quality assurance: build known-good samples and use them for data validation after every transformation.
Forensics and documentation: record the bytes behind control characters and special characters in an archived format.
Education: see how character encoding evolved from IBM System/360 to Unicode and UTF-8.

Control and non-displayable bytes

Control characters such as line feed or NEL have no visible shape, so they can only be understood by their hex value. Some references show a mnemonic like EOT instead of a glyph, and a few variants such as the Unisys version differ slightly from the IBM tables. When a character has no printable form, trust the byte, not the screen.

EBCDIC Encoding Converter Features and Limits

As an EBCDIC encoding converter, this page works entirely from the hex input and text you provide, runs in your browser with JavaScript, and needs no registration. A good EBCDIC to hex converter should also let you decode a result again, so the same page doubles as an EBCDIC to hex check in the opposite direction.

It helps to think of it as a code converter rather than a cipher. People sometimes search for how to encrypt or decrypt with EBCDIC, but nothing is hidden: the character mapping is a published table, and anyone with the same code page can reverse it. Its real job is compatibility. IBM mainframe and midrange systems store EBCDIC characters as raw EBCDIC bytes, and modern tools expect ASCII or UTF-8, so the hex view is the neutral meeting point between them. The same ebcdic encoding logic is what turns EBCDIC text to hexadecimal in a way every platform can display.

Checking a 14-Byte Field with the Text to EBCDIC Converter

Dana, a batch tester, has to confirm that an invoice header will land correctly in a COBOL field declared as PIC X(14). The record she wants is INV-60318 HOLD: fourteen characters, hyphen and space included. A test file arrives from an upload and she suspects the bytes are not what the job expects, so she works out the expected values first.

She enters the string into the converter, selects CP037 because the target LPAR uses the US code page, and clicks the convert button. The output reads C9 D5 E5 60 F6 F0 F3 F1 F8 40 C8 D6 D3 C4, which is 28 hex digits, exactly 14 bytes. She notes two spots worth checking: the hyphen should be 60 and the space should be 40.

Next she opens the uploaded file in a hex editor and compares byte by byte:

Bytes 1 to 3 read 49 4E 56, which is ASCII for "INV" rather than the expected C9 D5 E5.
Byte 4 reads 2D, the ASCII hyphen, instead of 60.
Byte 10 reads 20, an ASCII space, instead of 40.

Every byte matches the ASCII table, so the file never went through a translation step. Against the CP037 table, the uploaded 14 bytes are all wrong, and the layout of the COBOL field cannot be trusted. The cause is a binary-mode transfer of a file that was meant to be converted on the way in.

Her next action is concrete: she re-sends the same file in text mode with the CP037 translation selected, then repeats the hex check. This time byte 4 shows 60 and byte 10 shows 40, so the conversion is confirmed and the job can run against the record.

Tips for Accurate Text to Hexadecimal Results

Remove a leading 0x prefix if your source adds one, as most EBCDIC tools expect plain pairs.
Check uppercase and lowercase carefully, because they live in different byte ranges.
Keep a backup of the original file before any conversion, and test with a short sample first.
For long files, use batch processing and rely on error handling to flag a character the chosen code page cannot represent.
Remember that accented letters only exist in some code pages, and characters outside the table may be replaced by a dot or a substitute byte.

Going the other way

To turn bytes back into readable text, use a hex to EBCDIC tool, and for plain ASCII to hex work use a standard hex converter. Matching the code page on both sides guarantees a clean round trip, and a quick binary or decimal view of a byte can help when you are tracing a single value through a program.

Extended ASCII and ISO 8859-1

Many reference tables show EBCDIC beside extended ASCII, which is normally ISO 8859-1 for Western languages. If you compare the two, remember that the ASCII half is only seven bits wide, while every EBCDIC value uses the full eight. A lookup table of all 256 code assignments is the best companion for any manual check, and a hex editor or packet captures can confirm what really went over the wire.