Why does malformed UTF-8 produce an error instead of a replacement character?

Fatal decoding prevents damaged or non-UTF-8 bytes from being presented as verified original text.

Can I paste one continuous hexadecimal string?

Yes, if it contains an even number of hexadecimal digits; separated tokens and optional 0x prefixes are also accepted.

Is UTF-8 the same as Base64 or URL encoding?

No. UTF-8 maps Unicode scalar values to bytes; Base64 and percent encoding represent bytes for different transport contexts.

Why can one character use four bytes?

UTF-8 is variable width, and supplementary Unicode scalar values such as many emoji require four bytes.

How long can a UTF-8 byte sequence be?

One to four bytes per scalar value. ASCII characters are one byte, two-byte sequences cover U+0080 to U+07FF, three-byte sequences cover U+0800 to U+FFFF, and four-byte sequences cover U+10000 to U+10FFFF.

UTF-8 Decode Cheat Sheet: Patterns and Notation Reference

UTF-8 is a variable-width Unicode encoding standardized by RFC 3629 that uses one to four bytes per scalar value, where ASCII code points from U+0000 to U+007F remain a single byte and supplementary characters above U+FFFF require four bytes. A UTF-8 decode cheat sheet is therefore a compact reference of three things at once: the leading-byte ranges that signal sequence length, the bit patterns that pack code points into those bytes, and the input notation formats — hexadecimal, decimal, and binary — accepted by a strict decoder. With those three references in hand, decoding stops being guesswork and becomes a verifiable operation that rejects malformed input instead of silently substituting the U+FFFD replacement character. The cheat sheet below lists the four UTF-8 sequence shapes, the eight boundary code points that stress-test every decoder, the notation formats the UTF-8 Encoder / Decoder accepts, and the round-trip workflow that confirms an output is byte-identical to the source.

UTF-8 Byte Pattern Reference

A UTF-8 byte sequence is built from one leading byte that declares the total length plus zero to three continuation bytes. The leading byte's high bits are not arbitrary; they map directly to the scalar value range, which is why a single hex digit often tells you whether a one-byte character is enough. The pattern table below is the core of any UTF-8 decode cheat sheet because every decoder, whether in a browser, a programming language, or a hex editor, applies the same row to the same leading byte.

Code point range	Byte count	Leading byte	Continuation bytes
U+0000 – U+007F	1	0xxxxxxx	none
U+0080 – U+07FF	2	110xxxxx	10xxxxxx
U+0800 – U+FFFF	3	1110xxxx	10xxxxxx (×2)
U+10000 – U+10FFFF	4	11110xxx	10xxxxxx (×3)

The eight boundary code points below exercise every transition in the pattern table. Each entry shows the scalar value, the hex byte sequence, and the rule the sequence triggers. They come from the documented test set used by the UTF-8 Encoder / Decoder and correspond to RFC 3629 boundaries.

U+0024 ($) → 24 — ASCII single byte; the hex and ASCII digits match exactly.
U+0041 (A) → 41 — ASCII single byte; same observation as the dollar sign.
U+007F (DEL) → 7F — last one-byte value before the two-byte range begins.
U+00A2 (¢) → C2 A2 — two-byte sequence; leading byte C0 or higher signals a multi-byte start.
U+20AC (€) → E2 82 AC — three-byte sequence; leading byte starts with the bits 1110.
U+1F600 (😀) → F0 9F 98 80 — four-byte sequence; supplementary plane, leading byte starts with 11110.
U+0800 — first three-byte boundary; values from this point need three or more bytes.
U+10FFFF → F4 8F BF BF — maximum scalar; last valid four-byte sequence in the standard.

Hex, Decimal, and Binary Notation Compared

The same underlying UTF-8 byte sequence can be written three different ways. Cheat sheets that only show hexadecimal leave readers stranded when their source uses decimal or binary, so the table below records the rules a strict decoder enforces on each notation. Switching notation never changes the bytes; it only changes how they are displayed.

Notation	Output format	Accepted input
Hexadecimal	Uppercase two-digit bytes separated by spaces	Space- or comma-separated one- or two-digit hex tokens, optional 0x prefixes, or one continuous even-length hex string
Decimal	Integer values 0–255 separated by spaces	Integer tokens only, one per byte
Binary	Exactly eight 0/1 digits per byte	Exactly eight zero-or-one characters per token

These are display representations of the same byte array. A continuous hexadecimal string such as E282AC is accepted because it contains an even number of digits, while E282A is rejected as malformed. Decimal input rejects any token outside 0–255, and binary input rejects any token that is not exactly eight characters long. Empty input decodes to empty text.

Decode Errors and What They Signal

A fatal decoder fails on five classes of malformed input rather than producing a U+FFFD replacement character. Recognizing each class by its byte signature is part of the cheat sheet because it tells you what to fix in the source rather than trusting the output.

Overlong encoding (e.g. C0 AF): the same scalar value encoded with more bytes than necessary, forbidden by RFC 3629.
Truncated sequence (e.g. E2 82): a multi-byte sequence cut off before all continuation bytes appear.
Isolated continuation byte: a byte matching the pattern 10xxxxxx that is not preceded by a valid leading byte.
Surrogate encoding: a value from U+D800 to U+DFFF encoded as UTF-8 even though surrogate scalar values are reserved.
Out-of-range value: any sequence that would decode above U+10FFFF, the highest permitted scalar.

When one of these errors is raised, the input is rejected wholesale. The decoder does not attempt to recover or to display replacement glyphs as if they were original text. That behavior is the reason a round-trip check is meaningful at all: a fatal decode tells you the bytes are real UTF-8 or tells you they are not.

Decoding UTF-8 Bytes With the Tool

Open the UTF-8 Encoder / Decoder and choose the UTF-8 bytes to text direction.
Select hexadecimal, decimal, or binary notation so the parser matches the format of your input.
Paste the bytes into the input field using the strict rules for the selected notation — continuous even-length hex, separated tokens, or eight-bit binary groups.
Select the conversion button to run the fatal decoder and read the output in the result panel.
Compare the byte count reported by the result panel against the number of bytes you supplied, then encode the result back to bytes and check for an exact match.

The same sequence in reverse handles encoding. Choose Text to UTF-8 bytes, pick the notation you want for the output, paste Unicode text, and select the conversion button. The encoder rejects unpaired UTF-16 surrogate code units so a claimed lossless conversion does not silently change your input. Valid surrogate pairs that represent supplementary characters are accepted normally.

For a single calculation, the euro sign trace below shows how a three-byte sequence is built from a code point. U+20AC has 16 useful bits: 0010 0000 1010 1100. The three-byte template is 1110xxxx 10xxxxxx 10xxxxxx, so the bits split into groups of 4, 6, and 6. Substituting gives 11100010 10000010 10101100, which renders as hex E2 82 AC — the same byte sequence listed in the boundary reference above. Decimal 226 130 172 and binary 11100010 10000010 10101100 are the same three bytes in different notations.

Round-Trip Verification Before Replacing Data

A decode is only trustworthy if encoding the result reproduces the original bytes. With the UTF-8 Encoder / Decoder, that means decoding your byte input to text, copying the text, encoding it back to the same notation, and comparing the two byte sequences for an exact match. The 200,000 UTF-16 code unit input cap and the 200,000-byte decoded notation cap exist to keep this verification responsive, so start with a short known sample and grow from there.

Keep a copy of the original data until the round trip matches. If the bytes are legacy content such as Windows-1252 or Shift JIS, the decode will fail, and that failure is information: it tells you the source is not UTF-8. Trying to force legacy bytes through a UTF-8 decoder only masks the real encoding, so identify the actual encoding before re-encoding.

All text and bytes stay in the current tab during the verification. Nothing is uploaded, logged, stored, normalized, translated, escaped, or copied automatically. That local-only behavior makes the check safe for sensitive content, but it also means you must preserve the source bytes yourself before replacing them in any pipeline. For data larger than the input cap, or for binary files, use a dedicated binary tool rather than the decoder.