Hex to Text

What does hex to text conversion do?

It turns a string of hexadecimal byte values back into the characters those bytes encode. This converter reads the hex in pairs, treats the bytes as UTF-8, and prints the text. 48 69 gives Hi, e2 82 ac 20 31 30 gives € 10, and e4 bd a0 e5 a5 bd gives 你好. Spacing and letter case don't matter, as long as there's an even number of hex digits.

Unlike many decoders, it refuses to guess. If the bytes aren't valid UTF-8, you get an error naming the problem instead of a page of question marks.

Using it

1. Paste the hex. Pairs may be separated by spaces or line breaks, or run together like 636166c3a9.
2. Click Convert.
3. Read the text, or the error if the bytes don't decode.

The 636166c3a9 example decodes to café. The first three pairs are ASCII letters, one byte each. The last two, c3 a9, form a single two-byte character, é.

Why strict decoding is useful

Most software decodes bad UTF-8 by substituting U+FFFD (�) and carrying on. That's fine for displaying a web page but bad for debugging, because it hides exactly the information you need. This page uses the browser's TextDecoder with its fatal flag on, which follows the UTF-8 decoder in the WHATWG Encoding Standard and stops at the first invalid sequence. If you get text back, every byte was valid. If you don't, something in the data isn't UTF-8.

Why a sequence is rejected

All of these fail with "These bytes are not valid UTF-8 text — check for a missing or extra byte in a multi-byte character." The cause is usually one of these:

Truncation is the most common in practice. It happens when a string is cut to a byte limit in the middle of a character, or when a hex dump is copied starting partway through a line. Check the first and last few pairs first.

Diagnosing garbled text

Strict decoding can also show you how text got mangled. A common case is a word like café that shows up somewhere as café. Dump the bytes of the stored value and decode them here:

• 63 61 66 c3 a9 decodes to café. The storage is correct UTF-8, so the problem is in whatever displayed it, which is reading UTF-8 as Latin-1 or Windows-1252.
• 63 61 66 c3 83 c2 a9 decodes to café. The data itself is double-encoded: correct UTF-8 bytes were misread as Latin-1 and encoded to UTF-8 a second time, so c3 became c3 83 and a9 became c2 a9. The fix belongs at the point where data was written, not in the display.
• 63 61 66 e9 fails as invalid. The data is in a single-byte encoding and needs converting to UTF-8.

That three-way split, display bug, double encoding or wrong encoding, covers most mojibake reports.

Byte order marks

Some editors write the bytes ef bb bf at the start of UTF-8 files. Many decoders quietly strip that mark, but this one keeps it, because the point of the page is to show what the bytes really contain. ef bb bf 48 69 gives Hi with an invisible zero-width character, U+FEFF, in front of it. The same goes for a BOM in the middle of the data. You can expose it with text to ASCII, where it shows as 65279, and converting the output back with text to hex returns the original ef bb bf 48 69. If you don't want the mark, delete the first three bytes before converting.

Related tools

To produce hex from text, including emoji and accented letters, use text to hex. If your hex has 0x prefixes or dump offsets that need removing first, the hex to ASCII guide shows how to clean each format. For data encoded as Base64 instead of hex, the Base64 decoder also decodes the result as UTF-8.