How do you convert hex to ASCII?
Read the hex two digits at a time. Each pair is one byte, and each byte below 80 is an ASCII character: 48 is H, 65 is e, 6c is l. Paste a string like 48 65 6c 6c 6f or 48656C6C6F here, click Convert, and you get Hello. Spaces between pairs are optional and letter case doesn't matter.
Doing it by hand, 48 means 4 × 16 + 8 = 72, and 72 is H in the ASCII code set defined in RFC 20. The ASCII table lists every pair from 00 to 7f if you want to check one.
Where hex strings come from
Hex is how most tools display raw data, so you'll meet it in places like these:
- Packet captures: Wireshark's "Copy as Hex Stream" gives one continuous run of digits.
- Database exports: MySQL's
HEX('Hi')returns4869, and SQL Server shows binary columns as0x4869. - Firmware, memory and file dumps from
xxdorhexdump. - Log files that hex-encode payloads so binary data can't break the log format.
- Source code byte arrays such as
{0x48, 0x69}.
Some of these paste straight in. Others need a quick clean-up.
Cleaning the input first
The decoder accepts hex digits and whitespace, nothing else. Here's what to strip from each common format:
| You have | Example | What to do |
|---|---|---|
| Plain pairs | 48 69 or 4869 |
Nothing, paste it |
0x prefixes |
0x48 0x69 or 0x4869 |
Delete every 0x |
| Escape sequences | \x48\x69 |
Delete every \x |
| Colon-separated | 48:69 |
Replace : with a space |
| Comma-separated array | {0x48, 0x69} |
Delete braces, commas and 0x |
| Percent-encoded | %48%69 |
Use the URL decoder instead |
| Hex dump with offsets | 00000000 48 69 0a plus a text column |
Remove the offset and the text column (see below) |
Find and replace handles all of the prefix and separator jobs. Anything left over that isn't 0 to 9 or a to f gives the error "Enter hex byte pairs, e.g. 48 69 or 4869."
Decoding a hexdump line
A line of hexdump -C output looks like this:
00000000 48 65 6c 6c 6f 2c 20 57 6f 72 6c 64 0a |Hello, World.|
- Delete the offset at the start,
00000000. It's a position counter, not data. Leave it in and it's valid hex, so it would silently decode as four invisible NUL bytes in front of your text. - Delete the text column between the
|bars. The dump tool already wrote its own best guess there, and the|characters would make the input invalid. - Paste the remaining pairs and click Convert. You get
Hello, Worldfollowed by a line break, since0ais a line feed.
For multi-line dumps, repeat for each line, or delete the first 10 characters and everything from the first | on each line in a text editor that supports column selection.
Mistakes the decoder catches, and one it can't
Because all whitespace is removed before the digits are paired, the decoder checks only that the total count is even and that every character is hex. That leads to a few behaviours worth knowing:
48 6is rejected: three digits can't form whole bytes.4 869is accepted and givesHi, because spacing is ignored. Odd spacing is harmless.- If you lose one digit somewhere in the middle and another one elsewhere, the count is even again, every pair after the first gap is shifted, and you'll get valid but wrong text. When output turns to junk partway through, look for a dropped digit just before that point.
00decodes to a NUL character. It's in the output even though you can't see it, and it will come along when you copy.ef bb bf, the UTF-8 byte order mark some editors put at the start of a file, is kept too, as an invisible U+FEFF in front of the text. Delete those three bytes first if you don't want it.
Bytes from 80 to ff
Strict ASCII ends at 7f. Higher bytes are decoded as UTF-8, so the multi-byte pair c3 a9 comes out as é. A high byte that doesn't belong to a valid UTF-8 sequence, such as e9 from a Latin-1 file, stops the conversion with an error rather than inventing a character. If you're working with international text and need to understand those errors, hex to text goes through them case by case.
To go from text to hex, use ASCII to hex.
Last updated