Hex to Text Converter

Paste a string of hex, get the text it spells out, and it runs both directions, live as you type. Everything stays on your own machine, nothing you paste is uploaded or logged, so you can decode a hex string you'd rather not hand to some random website. The real reason to reach for this one over the dozen other "hex to text" boxes online is a trap most of them quietly fall into.

A lot of those tools are hex to ASCII converters with a nicer name. They read each byte as one character and stop there. Fine for plain English, where one letter is one byte, and it falls apart the second your text has an accent, a non-Latin script, or an emoji. Paste the two bytes c3 a9 into one of those and you get é, two garbage characters, instead of the single é they actually stand for. This one decodes real UTF-8, so c3 a9 comes back as é, a four-byte emoji comes back as that emoji, and Greek, Cyrillic, or Japanese all land correctly.

And when your hex genuinely isn't valid text, it says so instead of guessing. Give it a stray g or an odd digit count and it points right at the problem, rather than printing a row of replacement boxes and leaving you to wonder whether the hex was wrong or the tool choked on it.

1. Pick a direction. Hex → Text turns hex into readable characters. Text → Hex goes the other way.
2. Paste or type into the top box. Decoding, your hex can be spaced, run together, comma or colon separated, or carry 0x / \x prefixes. Encoding, type any text, accents and emoji included.
3. Read the result underneath. It updates on every keystroke, there's no convert button to press.
4. For encoding, the three toggles shape the output: Space between bytes, a 0x prefix, or Uppercase letters.
5. Copy result grabs the output, Swap flips the direction and feeds the result back through, and Clear starts you over.

Every hex-to-text conversion is two hops. First the hex gets read two digits at a time into bytes, so 48 is 72, 65 is 101, 6c is 108. Those are just numbers, 0 to 255, no meaning yet. Then those numbers get looked up in a character table, and which table you use decides everything. 72 is H, 101 is e, 108 is l, and 48 65 6c 6c 6f reads out as Hello.

For plain English it barely matters which table, since ASCII and UTF-8 agree on every character below 128, A is 41 in both. The difference shows up once you go past the English keyboard. ASCII has no number for é, a Cyrillic letter, a euro sign, or an emoji, it ran out of room back in the 1960s at 128 characters. UTF-8 covers all of it by spending more than one byte on the bigger characters.

That's why é is two bytes, not one. Its Unicode code point is 233, too big for a single byte, so UTF-8 stores it as c3 a9. Encode é here and you get c3a9 back, four hex digits for one character, and most emoji cost four bytes, eight hex digits for a single glyph. That's the honest byte count, not a quirk to route around, and a converter that only understands one byte per character has no way to give it to you.

Knowing this pays off when you're debugging. If you've ever seen café turn into café on a web page, that's this exact mismatch caught in the act, the UTF-8 bytes got read as if each were its own Latin-1 character. The garbled é is just the c3 a9 bytes shown through the wrong table, and recognizing them as one character rather than two is often what untangles the bug.

Hex shows up in a few spacings that all mean the same bytes. Spaced (48 65 6c 6c 6f) is the readable hex-dump form. Run together (48656c6c6f) is what you find in a config value or a hash. Prefixed (0x48 0x65) is how source code and debuggers write it, with \x48 as a common variant. When you paste hex to decode, this tool strips all of that first, the spaces, newlines, tabs, commas, colons, and any 0x or \x on each byte, then decodes whatever hex is left. Paste straight from a debugger, a config file, or a solid run of digits and you get the same answer.

Where it won't bend is on correctness. If there's a character in your hex that isn't a hex digit, it stops and names it, "found g", instead of dropping it silently. An odd number of digits gets flagged too, since each byte is two digits and an odd total means one went missing. And bytes that decode to something that isn't valid text get caught, rather than filling the box with replacement characters. When you're debugging, a plausible-looking wrong answer is the worst thing a tool can hand you, so a clear error you can act on beats a silent guess.

The place this comes up most is a hex dump, the side-by-side view a hex editor or packet analyzer shows: an address on the left, the bytes as hex pairs in the middle, and an ASCII rendering on the right where printable characters show as themselves and everything else shows as a dot. You spot an interesting run of bytes, want to know what it says, so you copy it in here and decode.

File formats announce themselves in those first few bytes. A PNG image opens with 89 50 4e 47, and 50 4e 47 spells PNG. A PDF starts with 25 50 44 46, which is %PDF. A ZIP archive begins with 50 4b, which decodes to PK, the initials of Phil Katz, who wrote the format. Half-reading a dump gets easier once a handful of byte values stick, 20 is a space, 0a a newline, 41 capital A.