Hex to Text

This tool converts a hex string to text in your browser. The hex is parsed locally; nothing leaves your machine. For the reverse direction, see text to hex.

How the conversion works

Input:  48 65 6c 6c 6f
Step 1: each two-hex-digit pair is one byte
         48 = 72,  65 = 101,  6c = 108,  6c = 108,  6f = 111
Step 2: bytes interpreted as UTF-8
         72  =  H
         101 =  e
         108 =  l
         108 =  l
         111 =  o
Output: Hello

Hex is base-16 — each digit represents 4 bits, so two digits = 8 bits = 1 byte. That’s why hex pairs are the standard way to display bytes: dense, case-insensitive, unambiguous.

What inputs are valid

The tool above accepts:

• Hex pairs separated by whitespace. 48 65 6c 6c 6f — the cleanest form.
• Continuous hex string. 48656c6c6f — read two characters at a time.
• Common prefixes. 0x48 for individual bytes (the C/JavaScript notation); these are stripped.
• Mixed case. 48 and 4A and 4a all parse the same way; hex is case-insensitive.

It does not accept:

• Odd-length input. A single trailing hex digit 4 is half a byte; the tool flags this as an error.
• Non-hex characters. 4G or 48 ZZ — flagged with the offending position.

Encoding interpretation

Bytes 0–127 are unambiguous: they’re ASCII. Bytes 128–255 require an encoding to interpret:

The tool above decodes as UTF-8 because that’s what modern systems use; there is no encoding switch. If decoding produces � where you expected é, the bytes are probably Latin-1 or Windows-1252 — in those encodings each byte 0x80–0xFF is one character, which you can look up directly.

Multi-byte UTF-8

Characters above U+007F take multiple bytes in UTF-8. The byte structure:

Continuation bytes always start with 10. A start byte for a 2/3/4-byte sequence has a specific high-bit pattern. A standalone byte 0x80–0xBF (with no preceding start byte) is invalid UTF-8 — the tool above shows it as the replacement character �.

Example: 0xE2 0x9C 0x93 is the 3-byte sequence for ✓ (U+2713). The first byte’s 1110 says “3-byte start”; the next two are 10-prefixed continuation bytes.

Where you’ll see hex bytes

• Hex dumps. xxd, hexdump -C, od -x — Unix tools that show file contents byte-by-byte in hex.
• Network captures. Wireshark, tcpdump output. Raw packet bytes shown as hex.
• Memory inspections. Debuggers, kernel dumps, crash reports.
• Cryptographic outputs. Hashes, signatures, keys — usually printed as hex.
• Color values. CSS uses hex for colors (#ff00cc), with each pair being one channel byte. See color converter.
• Binary protocols. The bytes of an HTTP/2 frame, a TLS handshake, a TCP packet — all hex when documented.

Hex vs other byte representations

For binary form, see binary to text. For base64, see base64 decode.

Common pitfalls

• Wrong encoding. Bytes that decode cleanly as Latin-1 produce mojibake when decoded as UTF-8. If the source is older (pre-2010), suspect Latin-1 or Windows-1252.
• Endianness for multi-byte values. Hex bytes have no inherent endianness — they’re a byte-by-byte dump. But interpreting four bytes as a 32-bit integer requires knowing whether they’re big-endian (0x12 0x34 0x56 0x78 → 0x12345678) or little-endian (→ 0x78563412). The tool decodes as a string, not as an integer; for integer interpretation, you need a different tool.
• Whitespace in unexpected places. Some hex dumps include a 16-character ASCII column on the right (xxd does). The tool above accepts whitespace as a separator, so the ASCII column has to be stripped before pasting.
• 0x prefix stripping. 0x4A is one byte; 0x48 0x65 are two bytes. The tool strips 0x and \x prefixes and also accepts , : and - as separators (48:65:6c).
• Invalid UTF-8 sequences. A continuation byte without a start, or a truncated multi-byte sequence, isn’t valid UTF-8. The tool doesn’t stop; it shows � at that spot so you can see where the garbage is.

For the inverse direction, see text to hex. For the broader binary view, binary to text. For looking up specific ASCII codes, ASCII table.