Convert hexadecimal back to text, accepting spaces, commas, colons and 0x prefixes, and warning when the bytes decode to something other than clean UTF-8.
Show calculation steps
Processed privately in your browser — nothing you paste is uploaded, logged or stored.
Reading a hex dump back
Each pair of hex digits is one byte, and the bytes are then decoded through a character encoding. Both halves can go wrong independently: an odd number of digits means the dump is truncated, and a byte sequence that is not valid UTF-8 means the encoding assumption is wrong.
Worked example
48 65 6c 6c 6f → "Hello"
c3 a9 → "é" read as UTF-8
→ "é" read as Latin-1 (same bytes)Formats accepted
Spaces, newlines, colons and 0x prefixes are all ignored, so hex pasted from Wireshark, a hex editor, a log line or source code decodes without reformatting. Anything that is not a hex digit is reported rather than dropped, since a stray character normally means the copy was incomplete.
What a failed decode tells you
An invalid UTF-8 sequence is information, not an error to hide. It usually means the data is not text at all — an image header, a compressed block, an encrypted payload — or that it is text in another encoding entirely. The tool says which, rather than returning replacement characters.
Limits
Only the bytes you paste are examined; there is no attempt to detect a file type. Decoding runs in your browser, which matters because hex dumps so often come from production captures.
How to use the Hex to Text
- Paste your hex values. Spaces, commas, colons and 0x prefixes are all removed automatically.
- Choose whether the values are UTF-8 bytes or Unicode code points.
- Click "Convert to text".
Frequently asked questions
Which separators are accepted?
Spaces, commas, semicolons, colons, full stops, underscores and hyphens, plus 0x prefixes. You can paste hex straight from a debugger, a packet capture or source code without cleaning it up first.
Why does an odd number of hex digits fail?
Every byte needs exactly two digits, so an odd count means at least one digit is missing. Rather than silently pad the value, the tool reports the truncation and tells you how many digits it found.
I see the replacement character in the output. What does that mean?
The bytes are not valid UTF-8 at that point. Either the data is binary rather than text, the copy is truncated mid-character, or the original used a legacy single-byte encoding.
