UTF-8 decoding converts a sequence of UTF-8 bytes into Unicode text by grouping leading and continuation bytes into complete character values and applying UTF-8’s validity rules. A Unicode code point is not a byte: valid scalar values use one through four bytes, while ASCII retains its one-byte numeric values.
The UTF-8 Encoder / Decoder encodes Unicode text into hexadecimal, decimal, or 8-bit binary byte notation and decodes those notations back to text, entirely in the browser. Use the display notation to inspect a byte sequence, then confirm that the decoded text re-encodes to the same bytes.
For a trustworthy result, distinguish a valid transformation from a guess about the source data’s intended meaning.
The decoding model in plain English
Unicode assigns a scalar value to each valid Unicode character. UTF-8 encodes that scalar as a byte sequence: the leading byte indicates the sequence width, and the continuation bytes supply the remaining value bits. Decoding reverses those steps; it does not read one byte for every visible character.
These rules are defined by RFC 3629 and the Unicode Core Specification. UTF-8 permits scalar values through U+10FFFF and excludes surrogate code points. Consequently, an encoded surrogate is invalid UTF-8 rather than another way to represent a character.
How byte width reveals character range
One-byte scalars cover U+0000–U+007F; two-byte scalars cover U+0080–U+07FF; three-byte scalars cover U+0800–U+FFFF except surrogates; and four-byte scalars cover U+10000–U+10FFFF. U+007F is therefore the final one-byte scalar, while U+0800 is the first scalar that requires three bytes.
Verified UTF-8 reference points make these widths visible:
| Text | Unicode scalar | UTF-8 hexadecimal bytes | Width |
|---|---|---|---|
| $ | U+0024 | 24 | One byte |
| A | U+0041 | 41 | One byte |
| ¢ | U+00A2 | C2 A2 | Two bytes |
| € | U+20AC | E2 82 AC | Three bytes |
| 😀 | U+1F600 | F0 9F 98 80 | Four bytes |
| Maximum scalar | U+10FFFF | F4 8F BF BF | Four bytes |
The hexadecimal spaces separate bytes, not Unicode characters. Each byte in a multi-byte sequence participates in reconstructing one scalar value.
Hex, decimal, and binary views of the same bytes
The converter accepts three byte notations, but each has a distinct input syntax:
| Notation | Accepted decoding input | Output format |
|---|---|---|
| Hexadecimal | Space- or comma-separated one- or two-digit byte tokens, optional 0x prefixes on separated tokens, or one continuous even-length hexadecimal string | Uppercase two-digit bytes separated by spaces |
| Decimal | Integer tokens only, with each byte restricted to 0 through 255 | Decimal values from 0 through 255 separated by spaces |
| Binary | Tokens containing exactly eight zero-or-one characters | Exactly eight bits for every byte |
Changing the notation does not change the underlying UTF-8 sequence. For example, C2 A2, its decimal-byte form, and its eight-bit binary form all describe the bytes used to encode U+00A2. Empty input decodes to empty text.
UTF-8 is not Base64, URL percent encoding, HTML entities, hexadecimal numbers, encryption, or compression. It maps Unicode scalar values to bytes; those other formats serve different storage or transport purposes.
Why strict decoding rejects damaged input
The converter uses a fatal UTF-8 decoder, so malformed data produces an explicit error rather than a visible U+FFFD replacement character that could be mistaken for the original text. Common failures include:
- Overlong encoding: C0 AF attempts to represent a value using more bytes than necessary.
- Truncated sequence: E2 82 ends before the required continuation byte arrives.
- Isolated continuation byte: a byte marked as continuation data appears without a valid leading byte.
- Surrogate encoding: the bytes represent a forbidden UTF-16 surrogate code point.
- Out-of-range value: the sequence resolves above U+10FFFF.
An error can indicate either malformed notation or invalid UTF-8, so check the input format as well as the source encoding. In the encoding direction, the tool also checks for unpaired UTF-16 surrogate code units before using the browser’s TextEncoder. Although a platform encoder would normally replace such fragments with U+FFFD, this converter rejects them to avoid silently changing text during a claimed lossless conversion. Valid surrogate pairs representing supplementary characters are accepted.
Decode UTF-8 bytes into text
- Preserve the original data. Keep an untouched copy, especially when the source encoding is uncertain, and begin with a short known sample.
- Choose the decode direction. Select “UTF-8 bytes to text,” then choose hexadecimal, decimal, or binary to match the source notation.
- Enter strictly formatted byte tokens. For hexadecimal, use separated bytes such as C2 A2, comma-separated bytes such as C2,A2, or a continuous even-length string such as C2A2. Optional 0x prefixes are accepted on separated hexadecimal tokens. Binary tokens must each contain exactly eight bits.
- Run the conversion. Select the conversion button and wait for the result or an explicit error.
- Inspect the decoded text. Check that the visible result matches the expected application context. If decoding fails, correct the notation or identify the original encoding rather than forcing the bytes through UTF-8.
- Verify a round trip. Re-encode the exact decoded text using the same notation, then compare every resulting byte value with the source sequence.
- Replace only verified data. Keep the original until the decoded text and round-trip output both match expectations.
For the reverse workflow, choose “Text to UTF-8 bytes,” enter Unicode text, select the required notation, and inspect the byte boundaries before using the output elsewhere.
What a successful decode does not prove
A successful parse proves that the bytes conform to UTF-8; it does not prove that UTF-8 was the source’s intended encoding. A byte sequence has no visible meaning without that context. The converter assumes UTF-8 and does not auto-detect legacy encodings such as Windows-1252, Shift JIS, GBK, or the ISO-8859 families. If legacy bytes fail, identify their original encoding instead of forcing them through this UTF-8-only workflow.
UTF-8 bytes also differ from Unicode code points and JavaScript UTF-16 code units. The grinning face U+1F600 is one Unicode code point, four UTF-8 bytes, and normally two JavaScript UTF-16 code units. The tool does not normalize text, so canonically equivalent spellings are not silently rewritten into a preferred form.
A round trip confirms that the decoded text maps back to the same UTF-8 bytes. It does not establish the source’s semantics, repair damaged data, or turn UTF-8 into a transport format such as Base64 or URL encoding.
Limits and local data handling
- Text input: The converter accepts at most 200,000 UTF-16 code units. A supplementary character can consume two of those units.
- Decoded notation: The input is bounded at 200,000 bytes. Binary notation expands each byte to eight bits, increasing token parsing and output work.
- Large data: The converter does not stream large files or accept uploads. Use a dedicated binary tool for large data.
- Local processing: Text and bytes remain in the current tab. Nothing is uploaded, logged, stored, normalized, translated, escaped for another context, or copied automatically.
Read the result panel’s unit carefully because it reports bytes or code points according to the operation. A code-point count should not be treated as a UTF-8 byte count, and a byte count should not be interpreted as the number of visible characters.
Related reading: XOR Encryption Online for Large Text: 100,000-Byte Limits.
Related reading: Base32 Decode on Mac: A Strict UTF-8 Browser Workflow.