Convert hex to text
Decode hexadecimal into readable text with full UTF-8 support, any separator, 0x prefixes and a file input for hex dumps.
- Runs in your browser
- Nothing you enter is sent
- Free, no account
The converted value appears here.
Accents, CJK and emoji become multiple bytes each, exactly as they are stored on disk.
Applies to the generated output. Input is parsed with or without separators.
Reading hexadecimal
Hex is base 16: the digits 0–9 followed by A–F for ten to fifteen. One hex digit carries exactly four bits, so two of them describe one byte — which is the whole reason hex is the default way to look at binary data. A byte in decimal runs 0–255 with no fixed width; the same byte in hex is always exactly two characters, 00 to FF.
| Character | Hex | Decimal | Binary |
|---|---|---|---|
H | 48 | 72 | 01001000 |
e | 65 | 101 | 01100101 |
l | 6C | 108 | 01101100 |
| space | 20 | 32 | 00100000 |
| line feed | 0A | 10 | 00001010 |
UTF-8 versus single-byte decoding
This is where most hex decoders go wrong. If your source was modern text, it is almost certainly UTF-8, where anything outside plain ASCII spans several bytes:
éisC3 A9— two bytes.€isE2 82 AC— three bytes.😀isF0 9F 98 80— four bytes.
Decode those with a single-byte reader and you get the famous mojibake — é where
an é should be. If that is what you are seeing, switch the character set to UTF-8.
If instead you get replacement characters in UTF-8 mode, the data probably was Latin-1 after
all, or is not text at all.
Input formats this accepts
All of the following decode to Hi:
4869
48 69
48,69
48:69
0x48 0x69
\x48\x69 Anything that is not a hex digit is treated as a separator, so you can paste straight out of a spec, a config file or a chat message. What will not work is a full hex dump with offsets and an ASCII column — those columns look like data to the parser. Strip them first.
Common things you will find in a hex blob
| Bytes | Meaning |
|---|---|
EF BB BF at the start | UTF-8 byte-order mark — invisible, and the cause of many parser errors |
0D 0A | Windows line ending (CRLF); 0A alone is Unix |
C2 A0 | Non-breaking space — looks like a space, is not one |
00 padding at the end | A fixed-length field, not part of the string |
FF FE at the start | UTF-16 little-endian BOM — this is not UTF-8 at all |
Where hex shows up
Colour values in CSS, MAC addresses, hashes and checksums, memory addresses in a stack trace, packet captures, embedded-device protocol traces, Unicode codepoints, and the raw view in every hex editor. Being able to read a few bytes at a glance is a genuinely useful skill; this page exists for the times when you would rather not.
Questions
Does the input need spaces between the bytes?
No. Continuous hex, space-separated, comma-separated, colon-separated and 0x-prefixed forms are all parsed. Anything that is not a hex digit is treated as a separator.
Why do accented characters come out wrong?
Because the character set is set to ASCII/Latin-1. In UTF-8 an é is the two bytes C3 A9, and a single-byte decoder shows them as two symbols. Switch the character set to UTF-8.
It says the number of digits must be even.
Each byte is exactly two hex digits, so a valid dump always has an even length. An odd count usually means a leading zero was dropped somewhere — 0A written as A.
Can I decode a hex dump from Wireshark or xxd?
Yes. Paste it in, or drop the .txt file. Offsets and ASCII columns will be misread as data though, so strip them first — the parser has no way to tell a byte value from an offset.