A UTF-8 decode example is E2 82 AC: three hexadecimal bytes that decode to the euro sign (€) when the byte sequence is valid UTF-8. UTF-8 decoding has two stages: the notation is parsed into an ordered array of bytes, and those bytes are interpreted as UTF-8 under the encoding rules defined by RFC 3629. Hexadecimal, decimal, and 8-bit binary are only three views of that same byte array; changing the notation does not change the underlying characters. The UTF-8 Encoder / Decoder handles both directions, so you can start with Unicode text, inspect its UTF-8 bytes, or paste strict byte tokens and recover the text. Its decoder is fatal: malformed byte sequences produce an explicit error rather than a replacement character that could hide damaged data. All processing stays in the current browser tab. For a dependable result, start with a short known sample, confirm the selected notation, inspect every byte boundary, and decode the encoded result again before replacing any original data.
What a UTF-8 decoder actually does
Decoding is not a matter of placing byte values beside characters. First, the converter parses the selected notation into an ordered byte array. It then checks that the array follows the UTF-8 structure defined by RFC 3629: leading bytes identify a sequence length, continuation bytes complete it, and the resulting value must be a permitted Unicode scalar value. The Unicode Core Specification defines the scalar range used for that interpretation. Valid scalar values occupy one through four bytes. ASCII code points retain their one-byte values, while larger values use leading and continuation-byte patterns.
Keep three units separate: a byte is eight bits, a Unicode code point identifies a character, and a UTF-16 code unit is a storage unit used by JavaScript strings. A supplementary character can be one Unicode code point, four UTF-8 bytes, and typically two JavaScript UTF-16 code units. A byte sequence has no visible meaning until its encoding is known. This converter assumes UTF-8 only, so it does not guess whether arbitrary bytes belong to another character set.
Decode the example in the browser
Use bytes-to-text mode to validate a source sequence before treating it as text.
- Choose “UTF-8 bytes to text,” then select hexadecimal, decimal, or binary. Use hexadecimal for the E2 82 AC example.
- Paste the byte tokens in the strict format required by that notation. For this example, enter E2 82 AC as three space-separated hexadecimal byte tokens.
- Select the conversion button. The tool parses the tokens and attempts a fatal UTF-8 decode.
- Compare the exact output with the expected text and the selected source format. For this one sample, the decoded result should be the euro sign (€).
- Reverse the conversion: choose text to UTF-8 bytes, keep the same notation, and confirm that the regenerated bytes match E2 82 AC. Preserve the source data until both directions agree.
The comparison is important because successful notation parsing does not guarantee valid UTF-8. The converter checks both layers and refuses to present malformed bytes as verified original text.
Input rules for each notation
Choose the notation that matches the source rather than the format you wish it had. The converter supports these input and display rules:
| Notation | Accepted byte input | Display when encoding text |
|---|---|---|
| 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 value in the 0–255 range. | Byte values from 0 through 255 separated by spaces. |
| Binary | Exactly eight zero-or-one characters per byte token. | Exactly eight bits per byte. |
A 0x prefix belongs on separated hexadecimal tokens, not inside the continuous form. Empty input decodes to empty text. These rules govern notation only: correctly formed hex, decimal, or binary tokens can still describe malformed UTF-8 and fail decoding.
Reference values for a known-answer check
These standard UTF-8 values provide useful known-answer checks across ASCII, multibyte characters, supplementary characters, and boundary values.
| Character or boundary | Unicode scalar value | UTF-8 bytes |
|---|---|---|
| Dollar sign | U+0024 | 24 |
| A | U+0041 | 41 |
| Cent sign | U+00A2 | C2 A2 |
| Euro sign | U+20AC | E2 82 AC |
| Grinning face | U+1F600 | F0 9F 98 80 |
| Lower ASCII boundary | U+007F | 7F |
| Three-byte boundary | U+0800 | E0 A0 80 |
| Maximum scalar value | U+10FFFF | F4 8F BF BF |
The boundary values matter when diagnosing byte-level results. U+007F remains a one-byte value, U+0800 begins a three-byte pattern, and U+10FFFF is the maximum permitted scalar value. A purported four-byte sequence above that ceiling is invalid, not an extension point.
Errors that strict decoding exposes
A fatal decoder distinguishes parseable notation from valid UTF-8. Hexadecimal digits can be perfectly formatted and still describe bytes that no valid UTF-8 sequence can contain. The converter rejects:
- Overlong encodings such as C0 AF.
- Truncated sequences such as E2 82.
- Isolated continuation bytes.
- UTF-8 encodings of surrogate code points.
- Values above U+10FFFF.
These failures indicate that the bytes are not valid UTF-8, although the error alone does not reveal whether the source was truncated, corrupted, or encoded with a different character set. The decoder reports an explicit error instead of presenting replacement characters as verified text. On the encoding side, the tool also checks JavaScript strings for unpaired UTF-16 surrogates before calling TextEncoder. Lone surrogates would normally be replaced with U+FFFD, so the tool rejects them to avoid silently changing the input; valid surrogate pairs representing supplementary characters are accepted.
Verify the result with a round trip
A round trip checks that the decoded characters produce the original UTF-8 byte sequence again.
- Keep an untouched copy of the original byte notation.
- Decode the source and compare the exact result with the expected text.
- Encode that text back into UTF-8 bytes using the same notation.
- Compare the regenerated bytes with the original, checking byte values rather than only spacing or letter case.
The result panel reports bytes or code points according to the operation. A successful round trip shows that the decoded text re-encodes to the same UTF-8 bytes under the same assumptions, but it cannot prove that those bytes were intended to represent UTF-8 in the first place. Continue preserving the source when its origin is uncertain.
When the bytes use another encoding
This converter assumes UTF-8 only 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 rather than forcing them through UTF-8. UTF-8 bytes are also not the same thing as Unicode code points, UTF-16 code units, HTML entities, URL percent encoding, Base64, encryption, or compression. Base64 and percent encoding package bytes for different transport purposes; they do not define the Unicode-to-byte mapping that UTF-8 provides.
When a sequence decodes unexpectedly, first confirm that it really originated as UTF-8. A successful decode is evidence that the bytes form valid UTF-8, but a legacy byte sequence can occasionally also be valid under both encodings and therefore produce plausible but unintended text.
Limits and local processing
Input is bounded at 200,000 UTF-16 code units for text and 200,000 bytes for decoded notation. The converter does not stream large files or accept uploads, so use a dedicated binary tool for large data.
- All text and bytes remain in the current tab.
- Nothing is uploaded, logged, or stored.
- The converter does not normalize, translate, or escape text for another context.
- Results are not copied automatically.
These conditions make short, controlled conversions practical while reducing accidental exposure of source data. Preserve the original anyway, especially when decoding bytes from an unfamiliar system.
Start with a known sequence, confirm the notation, and require a clean round trip before relying on the decoded text. Strict validation is what turns a byte conversion into a result you can check instead of merely trust.