A character encoding with a separate history from ASCII
EBCDIC (Extended Binary Coded Decimal Interchange Code) was developed by IBM in the 1960s for its System/360 mainframes, around the same time ASCII was being standardized elsewhere. The two efforts didn't converge: EBCDIC evolved from IBM's earlier punched-card coding schemes, which had their own logic for how digits, letters, and punctuation were laid out on a card, while ASCII was designed somewhat independently with an eye toward a clean, contiguous layout convenient for sorting and arithmetic on the byte value. The result is that EBCDIC and ASCII don't just use different byte values for the same characters — their entire internal layout is structured differently, which is why there's no simple offset or bit-flip that translates one to the other; a full lookup table is required in both directions.
Why EBCDIC's letters aren't contiguous
One of the more surprising features of EBCDIC to anyone used to ASCII is that its uppercase letters aren't a single contiguous block of byte values. This tool implements code page 037 (CP037), the common US/Canada variant: A through I run 0xC1–0xC9, J through R run0xD1–0xD9, and S through Z run 0xE2–0xE9 — three separate blocks with gaps between them, rather than one unbroken run the way ASCII's A–Z (0x41–0x5A) is. Lowercase letters follow the same three-block pattern shifted to a different range. This traces back to EBCDIC's punched-card ancestry, where letters were grouped according to the physical zone-and-digit punch pattern used to represent them on a card, a constraint that has nothing to do with keeping letters in alphabetical byte order the way ASCII's designers prioritized.
What is consistent: digits and space
Despite the letter gaps, EBCDIC digits 0–9 do form one contiguous run, at 0xF0–0xF9— a deliberate design choice, since keeping digits in order matters for arithmetic and sorting in ways that letter contiguity doesn't for typical mainframe workloads (business data processing, not text sorting, was EBCDIC's primary use case). The space character sits at 0x40, EBCDIC's equivalent of ASCII's 0x20. This tool's lookup table covers the full 256-byte CP037 mapping, including control characters and punctuation, sourced from the Unicode Consortium's published EBCDIC mapping tables to avoid the transcription errors that a hand-built 256-entry table would risk.
Where EBCDIC still runs today
EBCDIC's continued relevance is almost entirely about installed infrastructure rather than any technical merit relative to ASCII or UTF-8. IBM mainframes (the z/OS operating system lineage) still process enormous volumes of transactional data — banking, insurance, airline reservations, government systems — much of it running software with decades of accumulated business logic that would be expensive and risky to rewrite. That software was built assuming EBCDIC internally, so file transfers, batch jobs, and integrations touching those systems still need EBCDIC-aware conversion at the boundary, which is the practical reason a hex-to-EBCDIC tool has ongoing use even though virtually no new software is designed around EBCDIC from scratch.
Code pages: EBCDIC isn't just one encoding
Much like extended ASCII fragmented into multiple vendor-specific variants for the unused 8th bit, EBCDIC exists in dozens of "code page" variants, each tuned for a different language or region — CP037 for US/Canada English, CP500 for international use, and others for various European languages, each moving accented characters and regional symbols into different byte positions. Two EBCDIC files using different code pages will decode most ASCII-range content (letters, digits) identically, since those core mappings tend to be shared, but can disagree entirely on accented characters and certain punctuation. This tool implements CP037 specifically because it's the most common default in US/Canada mainframe environments; a file known to use a different EBCDIC code page would need a different mapping table to decode correctly.
A conversion gotcha: transferring files between systems
A common real-world failure mode is transferring a file between an EBCDIC mainframe system and an ASCII/UTF-8 system without an explicit conversion step — FTP, for instance, has historically supported an "ASCII mode" specifically to handle this translation automatically for text files, as opposed to "binary mode," which copies bytes unchanged and would corrupt EBCDIC text if the receiving system expects ASCII. Choosing the wrong transfer mode produces a file that isn't just garbled but structurally different byte for byte, since (as with the letter-block gaps described above) there's no simple numeric shift between the two encodings — only a full character-by-character remapping restores the original text correctly.