EBCDIC to ASCII converter: seven code pages, side by side

What is EBCDIC?

EBCDIC is the character encoding IBM built for its mainframes in the early 1960s, and it is still what a great deal of banking, insurance and government data lives in. If you have ever opened a file from a mainframe and found readable-looking gibberish, EBCDIC is usually the reason: the bytes are fine, they simply do not mean what your editor assumes.

The first thing to know is that EBCDIC is not one encoding. It is a family, and the members disagree. This tool ships seven of them — the ones a general-purpose standard library actually implements — and lets you convert in either direction while showing which of your bytes the other six would read differently.

The second thing is stranger, and it is the reason a range check on letters is a portability bug rather than a matter of taste.

How to use it

1. Choose a direction and a code page. The page selector is always visible and never guesses, because a converter that quietly picks one is the mistake this tool exists to show. If you do not know which page a file uses, the disagreement table below is how you find out.
2. Paste your bytes or your text. Hex accepts spaces, commas and a 0x prefix, and reads a long run two digits at a time. Anything that is not hexadecimal is listed rather than silently skipped.
3. Read the panels underneath. One shows every byte in your input that the seven pages disagree about. One walks the letter range and counts what is in it that is not a letter. One tells you whether this page survives a round trip.

The letters are not consecutive

In ASCII the lowercase letters run from 97 to 122 with nothing in between, which is why everyone writes a range check to test whether a character is a letter. In EBCDIC that test is wrong, and not by a little.

On the American page, a is 0x81 and z is 0xA9. That is a span of forty-one byte values for twenty-six letters, so the range takes in fifteen values that are not letters at all. The run breaks twice: between i and j the value jumps by eight, and between r and s by nine. The tool draws the whole range for whichever page you have selected and highlights the intruders, so you can count them yourself.

The reason is the punched card. EBCDIC was designed so that a character's byte could be read straight off the card's zone and digit punches, and a zone only ever gave nine positions before the next one began. The letters were laid out in three groups of nine, nine and eight, and the gaps are where one zone ended. A layout that made perfect sense for card readers became, sixty years later, a trap for a one-line range check.

Digits, for what it is worth, are consecutive: 0 through 9 run from 0xF0 to 0xF9 without a break. It is only the letters that are interrupted, which is precisely why the mistake survives — half of what you remember about the layout is correct.

The pages disagree about brackets, not about letters

Take the two commonest Latin pages, the American one and the international one. They differ on exactly seven byte values out of 256, and the seven characters involved are the square brackets, the pipe, the exclamation mark, the caret, the cent sign and the not sign.

It is not a substitution but a shuffle: the same seven characters sit in the same seven byte positions on both pages, in a different order. Every letter and every digit is identical. So a file of prose moves between the two systems perfectly, and a file of source code arrives with its brackets turned into currency symbols. That is why the problem is remembered as a bracket problem rather than an encoding problem — the damage is concentrated in exactly the characters a programming language depends on and absent from everything else.

Across all seven pages here, only 150 of the 256 byte values mean the same thing everywhere. The disagreement panel is deliberately scoped to the bytes in your input rather than to the whole table, because the question worth answering is whether your file would read differently somewhere else.

Honest limitations

Seven code pages is not all of them. IBM has defined a great many more, and the seven here are the ones a general-purpose standard library implements, which is what made it possible to generate the tables from a source rather than typing them. If your file uses a page that is not listed, this tool cannot help and no amount of trying the others will make it right.

The round trip is not universal, and the tool says so per page rather than making a blanket promise. Five of the seven survive a decode and an encode back for all 256 values. The Hebrew page leaves thirty-eight byte positions unassigned, so those cannot come back from text — there was nothing there to begin with. The Greek page is different and more subtle: it assigns all 256, but seven of its byte values share a single placeholder character, so only one of that group can be encoded back and the other six are lost. Two different defects that look the same in a summary, which is why they are reported separately.

Finally, your browser cannot do any of this natively. The web platform's encoding standard lists the encodings a browser must support and states that it must not support any others; EBCDIC is not on that list and never will be. That is why the tables are shipped with the page rather than handed to a built-in decoder, and it is the same standard the character encodings list on this site is about, seen from the other side.

Why is it free?

Seven lookup tables of 256 entries each is about five kilobytes once compressed, and your browser does the conversion as you type. No server sees your data, so there is nothing to meter and no account to create.

Nothing is uploaded. Whatever you paste stays in this tab.