A UTF-8 encoder / decoder converts Unicode text into a sequence of well-formed UTF-8 bytes displayed as hexadecimal, decimal, or binary notation, and decodes those byte notations back into the original text using fatal error checking. UTF-8 is the variable-width encoding standardized by RFC 3629 that can represent every Unicode scalar value from U+0000 through U+10FFFF in one to four bytes per code point. The browser-based UTF-8 Encoder / Decoder combines both directions in one local panel so you can switch between encoding and decoding without copying data between sites. Encoding uses the browser's TextEncoder; decoding uses a fatal TextDecoder so overlong sequences, truncated sequences, isolated continuation bytes, surrogate encodings, and values above U+10FFFF are rejected with an explicit error instead of being silently replaced with U+FFFD. Both directions are bounded at 200,000 UTF-16 code units for text or bytes for notation so memory, parsing, and output stay predictable. Because the entire conversion runs locally in the current tab, neither your text nor the resulting bytes are uploaded, logged, normalized, translated, or copied anywhere else.
Encoding text to hex, decimal, or binary bytes
Hexadecimal, decimal, and binary are three display formats for the same underlying UTF-8 byte array; switching notation does not change the encoded sequence, only how each byte is written. The tool serializes every byte with a fixed shape: hex output uses uppercase two-digit bytes separated by spaces, decimal output uses values from 0 through 255 separated by spaces, and binary output uses exactly eight bits per byte. The letter A (U+0041) encodes as 41 in hex, 65 in decimal, and 01000001 in binary. The three bytes for the euro sign (U+20AC) appear as E2 82 AC in hex, 226 130 172 in decimal, and 11100010 10000010 10101100 in binary. Reference anchors that the converter can round-trip include the dollar sign U+0024 as 24, A as 41, the cent sign U+00A2 as C2 A2, the euro sign U+20AC as E2 82 AC, and the grinning face U+1F600 as F0 9F 98 80. Because UTF-8 is variable-width, a single character can take one, two, three, or four bytes depending on its scalar value; a four-byte emoji is still one Unicode code point and typically two JavaScript UTF-16 code units.
Encoding also checks for unpaired UTF-16 surrogate code units before calling the platform encoder, because JavaScript strings can contain these ill-formed fragments and the underlying TextEncoder would normally replace them with U+FFFD. The tool rejects unpaired surrogates so a claimed lossless conversion does not silently change your input; properly paired surrogate pairs that represent supplementary characters remain accepted.
Decoding byte notation back to Unicode text
The decode direction accepts strictly formatted byte tokens. Hexadecimal input may be one continuous even-length string such as E282AC, space-separated tokens such as E2 82 AC, comma-separated tokens such as E2,82,AC, or tokens with optional 0x prefixes such as 0xE2 0x82 0xAC; odd-length continuous strings are rejected up front. Decimal input accepts integer tokens only, such as 226 130 172. Binary input requires exactly eight zero-or-one characters per token, such as 11100010 10000010 10101100; shorter or longer tokens are rejected. Empty input decodes to empty text. The maximum scalar value U+10FFFF encodes to F4 8F BF BF in hex, the seven-bit boundary U+007F decodes from the single byte 7F, and the U+0800 boundary marks the lower edge of three-byte sequences.
Decoding is fatal. If the bytes do not form a valid UTF-8 sequence — for example an overlong encoding such as C0 AF, a truncated sequence such as E2 82, an isolated continuation byte, a surrogate value, or any sequence that would produce a scalar above U+10FFFF — the converter raises an explicit error rather than substituting U+FFFD. That guarantee keeps the result panel free of replacement characters that look like original text, which matters whenever you are verifying an unknown byte source. If your legacy bytes such as Windows-1252, Shift JIS, GBK, or any ISO-8859 family fail to decode here, the original encoding is something other than UTF-8 and forcing them through this tool will only produce errors; identify the source encoding instead.
Using the converter in three steps
The workflow is the same whether you are encoding Unicode text or decoding byte notation; the controls simply change direction and notation.
- Choose the direction — Text to UTF-8 bytes or UTF-8 bytes to text — then pick hexadecimal, decimal, or binary notation for the byte representation.
- Enter your Unicode text or paste the strictly formatted byte tokens into the input field, then select the conversion button to produce the result panel.
- Compare the result against your source format, run a round trip (encode then decode) on a short known sample, and only then replace your original data.
Start every session with a short known sample such as A, €, or 😀 so you can confirm the byte count and the notation rules before pasting a large block.
UTF-8 byte width reference
The table below summarizes the officially defined byte widths from RFC 3629. Each row shows the scalar range, the number of UTF-8 bytes a code point in that range requires, the leading-byte bit pattern, a worked example character, and the resulting hex bytes. The example values match the reference anchors used by the converter itself, so a round trip against this table is a useful sanity check.
| Scalar range | Bytes | Leading-byte pattern | Example | Hex bytes |
|---|---|---|---|---|
| U+0000 – U+007F | 1 | 0xxxxxxx | A (U+0041) | 41 |
| U+0080 – U+07FF | 2 | 110xxxxx 10xxxxxx | ¢ (U+00A2) | C2 A2 |
| U+0800 – U+FFFF | 3 | 1110xxxx 10xxxxxx 10xxxxxx | € (U+20AC) | E2 82 AC |
| U+10000 – U+10FFFF | 4 | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx | 😀 (U+1F600) | F0 9F 98 80 |
Valid Unicode scalar values stop at U+10FFFF and exclude UTF-16 surrogate code points (U+D800 through U+DFFF), so any byte sequence that would decode to a surrogate or to a value above U+10FFFF is rejected as malformed. For a deeper walkthrough of the decode direction specifically, see the UTF-8 decode guide.
Why fatal decoding rejects what other tools accept
Many decoders replace invalid bytes with U+FFFD, the official Unicode replacement character, so the result panel can show text even when the bytes were corrupted, truncated, or encoded with the wrong character set. The fatal decoder here refuses to produce text in those cases, which means every codepoint in a successful decode came from a well-formed sequence in your input. That property matters when you are verifying an unknown byte source: a replacement-character flood is the tell-tale sign of misdecoding, and the fatal mode surfaces the problem as an explicit error instead of hiding it inside the result.
The tool also assumes UTF-8 only and does not auto-detect legacy encodings such as Windows-1252, Shift JIS, GBK, or any ISO-8859 family. Bytes that decode cleanly as a legacy single-byte encoding will often fail here; that failure is useful because it tells you the original encoding is something other than UTF-8, which is information a silent replacement would have hidden. According to Unicode 17.0 Chapter 3, a byte sequence has no visible meaning without knowing its encoding, so identifying the source encoding is part of the verification workflow rather than a separate concern.
Limits, boundaries, and a verification workflow
The converter caps text input at 200,000 UTF-16 code units and decoded notation at 200,000 bytes, which bounds memory, token parsing, and result-panel size; it does not stream large files and does not accept uploads, so for multi-megabyte payloads reach for a dedicated binary tool. Every conversion runs locally in the browser, so input and output remain in the current tab and nothing is uploaded, logged, stored, normalized, translated, escaped for another context, or copied automatically.
Before you trust the converter on real data, run this short checklist:
- Start with a known sample such as A, €, or 😀 and confirm the byte count and notation match the reference values in the byte-width table.
- Encode that sample, copy the resulting bytes back into the decode panel, and verify the round trip returns the exact same text.
- Preserve the original data — keep an untouched copy of the source bytes until the round trip is confirmed.
- Inspect byte boundaries when pasting continuous hex: every pair of characters must align to byte boundaries, and odd lengths are rejected.
- Read any error as a signal to fix the input, not to retry with the same bytes; fatal errors mean the bytes were never going to round-trip.
UTF-8 bytes are not the same thing as Unicode code points, UTF-16 code units, HTML entities, URL percent encoding, Base64, hexadecimal numbers, encryption, or compression, so the result panel reports bytes or code points according to the operation you selected rather than mixing units. Keeping those distinctions clear is what turns a one-off conversion into a verifiable, repeatable step in your workflow.