Hex to Text Converter — UTF-8 Bytes & Back

What this tool does

It moves between text and the hexadecimal bytes underneath it. Hexadecimal is how bytes are usually written down — two digits, 00 to FF — so it shows up in file signatures, colour values, packet dumps and encoded payloads. This page decodes a hex string back into readable text and encodes text into hex, always through UTF-8 so a character that takes several bytes is handled correctly.

Bytes are not characters

The single most important thing about hex is that it counts bytes, not letters. "A" is the one byte 41, but "é" is two bytes (C3 A9 in UTF-8), and the emoji 👋 is four. That is why the hex form of a string is often longer than the string looks, and why treating hex as if each pair were a letter goes wrong the moment non-ASCII text appears.

Where hex shows up

Context	Why hex
File signatures	The first bytes identify a file type (PNG starts 89 50 4E 47).
Colours	#RRGGBB is three bytes written in hex.
Network / packets	Dumps and logs show raw bytes as hex.
Encoded data	Hashes, keys and tokens are shown as hex for compactness.

Reading hex with confidence

Two hex digits are always one byte, so a valid hex string has an even number of digits — an odd one means something is missing. Spaces and separators are cosmetic; only the digits matter. Keeping that in mind, the decoder here is deliberately forgiving about formatting and strict about the digits, which is the combination that avoids silently mangled output.

What the decoder does with each kind of input

Input	Result	Why
48 65 6C 6C 6F	Hello	Five bytes, valid UTF-8
48656C6C6F	Hello	Spaces are optional
0x48 0x65	He	0x prefixes are stripped
4	empty	A single nibble is not a byte; there is nothing to decode
E9	�	E9 alone is not valid UTF-8 — it is Latin-1 “é”, a different encoding
FF FE	��	Not UTF-8 text at all; almost certainly binary or another encoding

The replacement character � (U+FFFD) is the decoder telling you the bytes do not form text in this encoding. It is not a failure of the tool: the bytes were decoded, and the result is the honest answer that they are not valid UTF-8. The common causes are a string encoded with Windows-1252 or Latin-1 (where E9 is “é”), a truncated multi-byte sequence, or hex that is not text at all — a hash, a key, an encrypted blob. In those cases the bytes are still meaningful as bytes; they are just not characters.

This is also why hex decoding cannot be “fixed” by guessing an encoding. Guessing Latin-1 would turn the same input into text in the first case and into plausible-looking nonsense in the second, with no way to tell which happened. The replacement character keeps that ambiguity visible.

Hex, decimal bytes and octal are the same numbers

A byte has one value and several notations. Hello is 48 65 6C 6C 6F in hex, 72 101 108 108 111 in decimal and 110 145 154 154 157 in octal. All three describe the same five bytes, and converting text to one of them is just a different way of printing the same array. That matters when a tool or a log hands you bytes in an unfamiliar base: the binary and decimal converter switches between all four notations, and the UTF-8 inspector shows the same bytes alongside the characters, so a value can be cross-checked rather than trusted.

Uppercase and lowercase hex are the same value — 6c and 6C both mean 108 — and the output here is uppercase by convention, because file signatures and colour codes are usually written that way.

Frequently asked questions

Go deeper

Longer explanations of the problems this tool solves:

Bytes, hex and entities: the same text in four notations

Sources

• RFC 4648, The Base16, Base32, and Base64 Data Encodings.
• RFC 3629, UTF-8, a transformation format of ISO 10646.