Decode UTF-8 bytes to text
Turn UTF-8 byte sequences — hex like E4 B8 AD or decimal like 228 184 173 — back into readable text. Strict decoding, honest errors, in your browser.
Paste a byte dump and read it: E4 B8 AD decodes to 中, 228 184 173 to the same character. Formats can mix — commas, semicolons, 0x prefixes and trailing h suffixes are all tolerated. Hex is preferred when the input could read as either; decimal takes over when tokens can't be hex pairs, like the three-digit 228.
Decoding is strict: a sequence that violates UTF-8's rules — a truncated multi-byte character, a stray continuation byte — gets a clear error instead of the � replacement garbage other decoders quietly produce. When you're checking whether bytes are valid UTF-8 at all, an honest failure is the answer you need.
Use it to read hex dumps, decode byte arrays from logs and code, or verify an encoding by round-tripping against the text-to-UTF-8 encoder. All decoding runs in your browser tab — nothing is uploaded.
Frequently asked questions
- How does it tell hex from decimal?
- Every token is tried as hex pairs first (E4, 0xE4 and e4h all work). If the whole input reads as a hex stream and is valid UTF-8, that's your answer. Only when a token can't be a hex pair — like the odd-length 228 — does the decoder try decimal for the whole input. A clean hex stream that isn't valid UTF-8 stays an error rather than being misread as decimal.
- Why does my input fail with 'not valid UTF-8'?
- Because the bytes genuinely don't form valid UTF-8 — 80 alone, for example, is a continuation byte with no lead byte before it. That usually means the data is actually Latin-1, Windows-1252 or double-encoded, not that the tool is broken.
- What about Latin-1 or Windows-1252 bytes?
- Single bytes 0x80–0xFF are invalid UTF-8 by design. If your source data is in those encodings, convert it with a dedicated codec first — this decoder won't guess, because guessing is how mojibake spreads.