Hex to text converter

Bytes in, characters out

Text is stored as numbers. Each character is encoded as one or more bytes, and hex is the usual way to show those bytes. Decoding means reading the hex as bytes and then mapping the bytes back to characters with the right encoding.

Paste 48 65 6C 6C 6F and you get Hello: 48 is H, 65 is e, 6C is l (twice) and 6F is o. The byte map under the result shows each byte, or group of bytes, above the character it produced.

Notations it understands

Hex bytes turn up in many formats, and the tool accepts most of them as-is:

Format	Example	Typical source
Spaced	48 65 6C 6C 6F	hex editors, Wireshark
Continuous	48656C6C6F	hashes, database dumps
0x list	0x48, 0x65, 0x6C	C and Python source
Escaped	\x48\x65\x6C	strings in code, log files
URL-encoded	%48%65%6C	query strings
Colon-separated	48:65:6C	MAC addresses, certificates

Mixed case is fine. If there's an odd number of digits, or something that isn't a hex byte, you get a message naming the problem.

Choosing the encoding

The same bytes mean different text in different encodings, which is why there are four buttons.

UTF-8 is the default and covers almost all text on the web today. ASCII characters take one byte. Accented letters take two (é is C3 A9), most other scripts and symbols take three (✓ is E2 9C 93), and emoji take four (😀 is F0 9F 98 80).

ASCII is the original 7-bit set, bytes 00 to 7F only. Anything at 80 or above is flagged, which makes it a quick check for "is this plain ASCII?"

Latin-1 (ISO-8859-1) maps every byte to one character, with 80–FF covering Western European accented letters. E9 alone is é in Latin-1, but it's an invalid lone byte in UTF-8.

UTF-16 BE reads two bytes per unit, big-endian. Windows and Java use UTF-16 internally, so 00 48 00 69 (Hi) is a common sight in memory dumps and some file formats.

Spotting broken bytes

In UTF-8 mode, the tool walks through the bytes and checks each sequence. A byte that can't start a character, or a multi-byte sequence that is cut short, is shown in red and replaced with �. The message counts them.

This is how you diagnose mojibake, the garbled text you get when one encoding is read as another:

• "café" saved as UTF-8 and opened as Latin-1 shows as café, because C3 A9 is read as two separate Latin-1 characters.
• "café" saved as Latin-1 and opened as UTF-8 shows as caf�, because the lone E9 byte is invalid.

Paste the raw bytes and switch encodings until the text reads correctly. That tells you what the source encoding really was.

Control characters

Bytes below 20 are invisible control codes. The byte map shows the important ones as symbols: ↵ for a line feed (0A), ⇥ for a tab (09) and ␠ for a space (20), with a middle dot for anything else. A 0D 0A pair means Windows-style line endings. A file starting with EF BB BF has a UTF-8 byte order mark, and FF FE or FE FF at the start mark UTF-16.

Privacy

Decoding runs entirely in your browser. That matters, because pasted hex often comes from logs, packets or tokens you shouldn't send to a third-party server.

Related tools

To encode text into hex, use text to hex. If your hex string is really a single number, not text, use hex to decimal. For the bit patterns of each byte, try hex to binary.

FAQ

Why did I get Chinese-looking characters?

You probably decoded ASCII or UTF-8 bytes as UTF-16. Every pair of bytes became one character in the CJK range. Switch to UTF-8.

Is the euro sign 80 or E2 82 AC?

E2 82 AC in UTF-8. Byte 80 is the euro only in Windows-1252, a Microsoft extension of Latin-1. In true ISO-8859-1, 80 is an invisible control code.

Can it decode Base64?

No. Base64 is a different text representation of bytes. Decode it to bytes with a Base64 tool first, then convert those bytes here if needed.