Hex to text

Bytes are not text until you say how to read them

This is the thing most converters get wrong by omission: they convert hex to text without saying which encoding they used, which is fine for ASCII and produces mojibake for everything else.

The bytes E5 8F B0 are 台 in UTF-8. Read as Latin-1 they are three separate characters, one of which is an invisible control code. Both readings are valid. Only one is what you meant.

So the encoding is a visible control here, defaulting to UTF-8:

• UTF-8 — almost everything, since about 2010.
• Latin-1 — older Western European data, and the only encoding in which every possible byte sequence is valid text.
• UTF-16 LE / BE — Windows APIs, Java internals, and anything with a byte order mark. Byte order is a genuine choice, not a detail.

Invalid input is reported, not papered over

Bytes that are not valid UTF-8 produce an error naming the problem, rather than a string full of “ replacement characters.

That matters because a replacement character looks like data. Seeing one in the output, people reasonably assume the original contained it, and go looking in the wrong place. Being told “those bytes are not valid UTF-8 — try Latin-1” points at the actual answer.

An odd number of hex digits is also refused. Half a byte is not a byte, and guessing whether to pad the front or the back is a good way to produce confidently wrong output.

Bytes and characters are different counts

Both are shown, and the difference is usually why someone is here.

台北 is 2 characters and 6 bytes in UTF-8. A database column of VARCHAR(10) may mean ten of either, and which one decides whether the text fits. Emoji are worse: 👨‍👩‍👧 is five code points and 25 bytes.

What you can paste

48 65 6c 6c 6f, 48656c6c6f, 48:65:6C:6C:6F, 0x48, 0x65 and 48-65-6c-6c-6f are all read the same way. Separators are ignored and case does not matter.

Nothing is uploaded

Converted in this page. Hex dumps under inspection are often fragments of something private.