What "encoding" means, as distinct from base conversion
The tools in this section all convert hex bytes to and from a text or numeric representation, but unlike the tools under Base Conversion, none of them are just renaming the same integer in a different radix. Each one interprets the raw bytes according to a specific, independently-defined mapping table or convention — a character encoding standard, in most cases — so the conversion depends on that external mapping, not just on positional arithmetic. Getting the wrong mapping (assuming ASCII when the bytes are actually EBCDIC, for instance) produces a result that looks like valid output but is completely wrong, which is a different failure mode than a base-conversion arithmetic error.
ASCII and UTF-8: two eras of the same idea
ASCII, standardized in the 1960s, maps the 128 values representable in 7 bits to the English alphabet, digits, punctuation, and a handful of control characters. It was sufficient for early American computing but has no way to represent accented letters, non-Latin scripts, or symbols outside that original 128. UTF-8, designed decades later, solves that by using a variable number of bytes per character — ASCII text is stored identically in both encodings, byte for byte, which is precisely why UTF-8 became the dominant encoding for the web and most modern software: it's backward-compatible with the enormous existing base of ASCII text and software, while still being able to represent the entire Unicode character set when needed.
EBCDIC: a different lineage entirely
EBCDIC didn't evolve from ASCII and isn't compatible with it at the bit level — it was developed by IBM for mainframe systems along a separate historical path, and its digit and letter ranges fall in entirely different byte positions than ASCII's. A text file encoded in EBCDIC, opened by software expecting ASCII or UTF-8, doesn't produce a slightly garbled result — it produces bytes that decode to different characters entirely, unrelated to the original text. EBCDIC survives today primarily in IBM mainframe environments still running software with decades of history behind it, making it one of the few encodings where compatibility is dictated by existing infrastructure rather than any technical advantage.
BCD: encoding digits, not text
Binary-coded decimal takes a different approach from the other three tools here — it isn't about representing written language at all, but about storing decimal digits in a form that avoids the rounding and conversion overhead of binary floating-point arithmetic. Each decimal digit gets its own 4-bit nibble, so the hex representation of a BCD-encoded number literally displays the original decimal digits, just wrapped in hexadecimal notation. It shows up in contexts where exact decimal arithmetic matters more than compactness — older financial systems, calculators, digital clocks, and embedded systems that need to display or compute with decimal values without binary rounding error.
Why encoding mismatches are hard to detect automatically
A wrongly-decoded ASCII-vs-EBCDIC or ASCII-vs-UTF-8 mismatch is particularly troublesome because the output is often still valid-looking text — printable characters, no crash, nothing that obviously signals an error. UTF-8 has some built-in protection here: multi-byte sequences follow strict bit patterns, so feeding EBCDIC bytes through a UTF-8 decoder will frequently fail outright with an invalid-sequence error rather than silently produce wrong characters, because EBCDIC's byte patterns don't usually satisfy UTF-8's structural rules. Single-byte encodings like plain ASCII and EBCDIC offer no such protection — every byte value maps to some character in both encodings, so a wrong assumption always produces a result, just the wrong one, with nothing in the data itself signaling the mismatch.
Batch conversion for encoding work
Every tool in this section includes the same batch mode as the rest of the site: paste a list of hex values, one per line or comma-separated, and get every value decoded (or encoded) into a table you can export as CSV. That's useful for working through a list of byte sequences pulled from a log, packet capture, or file dump — checking whether a batch of values decode sensibly under a given encoding is often the fastest way to confirm or rule out that encoding as the right interpretation.
How to pick the right tool
If the bytes in question came from ordinary English-language software, a config file, or a network protocol built assuming plain text, ASCII is usually the right starting point, and UTF-8 is the right choice the moment accented characters, emoji, or non-Latin scripts are involved (which, on the modern web, is the large majority of text). EBCDIC only makes sense if the bytes are known to have come from an IBM mainframe environment or a data exchange format that explicitly specifies it. BCD applies specifically when the hex represents packed decimal digits rather than any form of text — recognizable because every nibble in a valid BCD value is 0–9, never A–F.