UTF-8 is a variable-width Unicode encoding that maps every valid Unicode scalar value to a sequence of one to four bytes, standardized in RFC 3629. To convert encoding to UTF-8 means turning text into that byte sequence, or reversing the process, using a representation you can read, copy, or paste into another system.
The UTF-8 Encoder / Decoder handles both directions directly in your browser. You can encode Unicode text into hexadecimal, decimal, or 8-bit binary byte notation, or decode any of those notations back into text. The converter pairs the browser's standard TextEncoder with a fatal TextDecoder, so malformed sequences such as overlong encodings, isolated continuation bytes, surrogate code points, and values above U+10FFFF produce an explicit error instead of being quietly substituted with the replacement character U+FFFD. Inputs are bounded at 200,000 UTF-16 code units for text and 200,000 bytes for byte notation, and nothing leaves the current tab.
How UTF-8 Uses One to Four Bytes
UTF-8 represents each Unicode scalar value as one, two, three, or four bytes depending on its numeric range. ASCII code points from U+0000 through U+007F keep their original one-byte values, which is why UTF-8 is a strict superset of ASCII and remains backward compatible with vast amounts of legacy data. Code points above U+007F use a leading byte that announces how many continuation bytes follow, plus that many continuation bytes carrying six payload bits each.
The full permitted scalar range runs from U+0000 to U+10FFFF, defined in the Unicode Standard's core specification. The UTF-16 surrogate range U+D800 through U+DFFF is excluded: those code points have no direct UTF-8 representation, and any attempt to encode them is invalid. Valid supplementary characters such as emoji above U+FFFF are encoded as four-byte sequences derived from a properly paired surrogate pair in the source.
Encode Unicode Text to UTF-8 Bytes
Follow these steps to produce an exact UTF-8 byte sequence from any Unicode text.
- Open the UTF-8 Encoder / Decoder and choose Text to UTF-8 bytes as the direction.
- Select the byte notation that matches your destination: hexadecimal, decimal, or 8-bit binary.
- Paste or type your Unicode text into the input area. The tool accepts up to 200,000 UTF-16 code units, including emoji, accented letters, and combining marks.
- Click the conversion button. The output panel renders the same byte array in your chosen notation.
- Compare the byte count reported in the result panel against the number of Unicode code points you entered. The two numbers will differ whenever your text contains supplementary characters, since one emoji equals one code point but four UTF-8 bytes.
As a concrete illustration, encoding the two-character string "A€" with hexadecimal notation produces the four-byte sequence 41 E2 82 AC. The first byte, 41, is the ASCII code for "A". The next three bytes, E2 82 AC, are the UTF-8 representation of the euro sign U+20AC: a leading byte announcing two continuation bytes, followed by two continuation bytes carrying the remaining bits. The total length is one byte for "A" plus three bytes for "€", giving four bytes for two characters.
Decode UTF-8 Bytes Back to Unicode Text
When you already have a UTF-8 byte sequence and need the original characters, run the conversion in the opposite direction.
- Select UTF-8 bytes to text as the direction.
- Choose the notation that matches what you have on hand: hexadecimal, decimal, or binary.
- Enter the bytes using the strict format the converter accepts. Hexadecimal input may be one continuous even-length string, or space- or comma-separated one- or two-digit byte tokens with optional 0x prefixes. Decimal input takes integer tokens only. Binary input requires exactly eight zero-or-one characters per token.
- Click the conversion button. If the bytes form a valid UTF-8 sequence, the original text appears; if not, the tool aborts with an explicit error.
- Verify the decoded text matches your expected source character by character before pasting it anywhere authoritative.
Comparing the Three Output Notations
Hexadecimal, decimal, and 8-bit binary are three display representations of the same underlying byte array. Switching notations never alters the encoded text; only the way the bytes are written changes.
| Notation | Format of each byte | Separator | Best for |
|---|---|---|---|
| Hexadecimal | Uppercase two digits, e.g. E2 | Space | Source code dumps, debugging logs, certificate inspection |
| Decimal | Integer 0 through 255, e.g. 226 | Space | Spreadsheets, byte arithmetic, protocols that quote decimal values |
| Binary | Exactly eight 0 or 1 digits, e.g. 11100010 | Space | Teaching byte structure, low-level protocol study, bitwise visualization |
If you need a hexadecimal-only flow or are encoding exclusively ASCII text, a dedicated text-to-hex converter serves a similar role but typically does not reject unpaired surrogates as strictly, so reach for the UTF-8 Encoder / Decoder when losslessness is mandatory.
Why Fatal Decoding Matters
Many decoders silently substitute the Unicode replacement character U+FFFD whenever they encounter a byte they cannot interpret. That behavior is convenient for displaying user input, but it hides corruption: a single stray byte in a 100 KB payload produces a single replacement character, and downstream code has no way to know whether the original character was missing, altered, or never present.
The UTF-8 Encoder / Decoder flips this behavior. It configures TextDecoder with a fatal flag, so the moment a sequence is overlong, truncated, contains an isolated continuation byte, encodes a surrogate, or exceeds U+10FFFF, the conversion aborts with an explicit error. The result panel reports bytes or code points according to the operation, and an empty input decodes to empty text rather than to a replacement character.
The same strictness is applied to encoding. The tool inspects the source string for unpaired UTF-16 surrogate code units, which JavaScript strings can technically contain, and rejects them before calling TextEncoder. Without that check, the platform encoder would substitute U+FFFD and the converted output would no longer round-trip to the original input.
UTF-8 Byte Patterns at Key Boundaries
The converter validates its encoder and decoder against fixed reference values drawn from RFC 3629 and the Unicode Standard. The table below shows each character rendered as a hexadecimal byte sequence.
| Character | Code point | UTF-8 bytes (hex) | Range |
|---|---|---|---|
| $ (dollar sign) | U+0024 | 24 | 1-byte ASCII |
| A (Latin letter) | U+0041 | 41 | 1-byte ASCII |
| ¢ (cent sign) | U+00A2 | C2 A2 | 2-byte, just above U+007F |
| € (euro sign) | U+20AC | E2 82 AC | 3-byte, just above U+0800 |
| 😀 (grinning face) | U+1F600 | F0 9F 98 80 | 4-byte supplementary |
| Maximum scalar | U+10FFFF | F4 8F BF BF | 4-byte upper bound |
Common Malformed Inputs That Are Rejected
The decoder intentionally fails on several patterns that lenient tools would silently accept. Knowing what fails helps you diagnose byte streams you receive from other systems.
- Overlong encodings such as C0 AF, which would encode U+002F using two bytes when one byte suffices. RFC 3629 forbids these to prevent alternate interpretations of the same scalar.
- Truncated sequences such as E2 82, where a leading byte announces continuation bytes that never arrive.
- Isolated continuation bytes, which fall in the range 80 through BF and appear without their expected leading byte.
- Surrogate encodings, which are UTF-8 sequences that map to values in U+D800 through U+DFFF and are not valid Unicode scalars.
- Values above U+10FFFF, including five- and six-byte sequences that older UTF-8 drafts once permitted but the current standard prohibits.
Limits, Privacy, and Round-Trip Verification
Inputs are bounded at 200,000 UTF-16 code units for text and 200,000 bytes for byte notation. These limits constrain memory, token parsing, output size, and interface responsiveness, so the tool does not stream multi-megabyte files. For bulk conversion, run the operation in batches rather than feeding the converter one massive input.
All encoding and decoding happens locally in the current browser tab. No data is uploaded, logged, stored, normalized, translated, escaped for another context, or copied automatically. This makes the tool suitable for payloads you would not want to send to a remote API.
Before replacing any original data, run a round-trip test: encode your source text, decode the output back, and confirm the decoded text matches the original character by character. If the two differ, the converter will normally have raised an error rather than produced silent replacements; investigate the offending byte rather than ignore the message. Preserve the original data until you have confirmed a clean round trip on a representative sample.