A strict UTF-8 decode API alternative runs entirely in your browser, accepts hex, decimal, and 8-bit binary byte notation, and rejects malformed byte sequences with a fatal error instead of substituting the U+FFFD replacement character. The UTF-8 Encoder / Decoder pairs the browser's standard TextEncoder with a TextDecoder configured for fatal mode, so overlong encodings, truncated sequences, isolated continuation bytes, surrogate encodings, and values above U+10FFFF all produce an explicit failure rather than a question mark. Each Unicode text input is also screened for unpaired UTF-16 surrogate code units before encoding, preventing the common platform behavior where JavaScript strings containing ill-formed fragments get silently rewritten during conversion. Hexadecimal output is uppercase two-digit bytes separated by spaces, decimal output ranges from 0 through 255, and binary output is exactly eight bits per byte. Input stays in the current tab, the page does not upload or log anything, and the operation is bounded at 200,000 UTF-16 code units of text or 200,000 bytes of notation to keep memory, token parsing, and the interface predictable.
Why Developers Replace Legacy Decode APIs
Many language-level decode helpers still hide their failures behind a single replacement character, which becomes a real problem the moment those question marks are written back to a file, sent over a network, or compared against a checksum. PHP's utf8_decode function was deprecated precisely because it dropped bytes that did not fit the target encoding and produced data the caller had no reliable way to verify. Python's codec layer offers //ignore and //replace error handlers that strip or substitute, but neither one halts the pipeline when a byte sequence is structurally illegal. The JavaScript TextDecoder does ship with a fatal option, yet most reference snippets leave it off and accept whatever bytes the caller pastes. A stricter alternative therefore needs to do two things at once: parse the byte notation strictly, and refuse to invent a character when the bytes do not encode one.
Fatal Decoding vs Silent Replacement Characters
The converter enables the fatal flag on the browser TextDecoder so any deviation from a well-formed UTF-8 sequence raises an error in the result panel rather than emitting a replacement character. That distinction matters in three situations: when you receive a payload from another service and need to confirm it really is UTF-8, when you are debugging an encoder that occasionally emits an overlong form, and when you are auditing legacy files for surrogate-encoded damage before a migration. The same fatal policy applies in reverse during encoding: JavaScript strings can contain unpaired UTF-16 surrogate halves from a bad paste or a partial stream, and the platform TextEncoder would quietly replace each one with U+FFFD. The converter checks for these fragments first and refuses the conversion if any are found, so the round-trip claim is verifiable rather than nominal. For deeper coverage of this approach, the guide on decoding UTF-8 bytes without silent replacement characters walks through the same fatal-flag reasoning in more detail.
Accepted Input Notations for Byte Sequences
Three notations describe the same underlying byte array, and each one is parsed by its own tokenizer. Hexadecimal output from the tool uses uppercase two-digit bytes separated by spaces, but the decoder also accepts comma-separated tokens, an optional 0x prefix on each separated token, or one continuous even-length hexadecimal string. Decimal input accepts integer tokens only, with values from 0 through 255. Binary input requires exactly eight zero-or-one characters per token, with no separators beyond whitespace.
| Notation | Token shape | Optional prefix | Continuous form | Sample for byte 0xC2 |
|---|---|---|---|---|
| Hexadecimal | One or two hex digits | 0x on each token | Yes, even length | C2 or 0xC2 |
| Decimal | Integer 0–255 | None | No, separated tokens | 194 |
| Binary | Exactly 8 bits | None | No, separated tokens | 11000010 |
Empty input decodes to empty text, which makes the round-trip check self-consistent. Anything that does not match the rules above — three-character hex tokens, decimal values above 255, binary tokens shorter or longer than eight characters — is rejected before the decoder runs, so the user sees the format problem rather than a corrupted text output.
Decode UTF-8 Hex, Decimal, and Binary to Text
- Open the UTF-8 Encoder / Decoder and set the operation selector to "UTF-8 bytes to text."
- Pick the notation that matches the source — hexadecimal, decimal, or binary — so the parser uses the right tokenizer and boundary rules.
- Paste the byte tokens into the input field. Hex accepts space- or comma-separated one- or two-digit tokens, optional 0x prefixes, or one continuous even-length string. Decimal takes integer tokens only. Binary requires exactly eight zero-or-one characters per token.
- Run the conversion. The decoder runs in fatal mode, so any malformed byte — including overlong encodings, truncated sequences, isolated continuation bytes, surrogate encodings, and values above U+10FFFF — raises an explicit error instead of returning a replacement character.
- Compare the resulting Unicode text with the source format, then re-encode it through the same tool to confirm a round trip before you replace any original data.
Anchored UTF-8 Sequences Worth Testing
Byte boundaries change as the scalar value crosses the limits that RFC 3629 defines, and a handful of anchor values expose encoding mistakes immediately. ASCII characters keep their single-byte form, values up to U+007F remain one byte, the U+0080 transition starts the two-byte range, U+0800 starts the three-byte range, and U+10000 starts the four-byte range used by most emoji. The table below lists the values the converter itself uses for its built-in tests.
| Scalar value | Meaning | UTF-8 bytes (hex) | Byte count |
|---|---|---|---|
| U+0024 | Dollar sign $ | 24 | 1 |
| U+0041 | Letter A | 41 | 1 |
| U+007F | ASCII boundary | 7F | 1 |
| U+00A2 | Cent sign ¢ | C2 A2 | 2 |
| U+0800 | 3-byte boundary | E0 A0 80 | 3 |
| U+20AC | Euro sign € | E2 82 AC | 3 |
| U+1F600 | Grinning face 😀 | F0 9F 98 80 | 4 |
| U+10FFFF | Maximum scalar | F4 8F BF BF | 4 |
If your bytes happen to be a different encoding such as Windows-1252, Shift JIS, GBK, or any ISO-8859 family, forcing them through UTF-8 will always fail — and that failure is the diagnostic. Treat the fatal error as a signal to identify the original encoding rather than as a problem to mute.
Limits, Privacy, and Round-Trip Verification
The converter caps text input at 200,000 UTF-16 code units and decoded byte notation at 200,000 bytes, which keeps the worst-case allocation predictable and prevents the page from hanging on oversized pastes. It does not stream files, accept uploads, or call a remote service; the entire conversion runs against the page's own JavaScript, with no logging, normalization, translation, escaping, or automatic copying of the result. To verify a conversion before swapping it in for an original artifact, encode the suspected text to bytes in your chosen notation, then paste the byte output back through the decoder side. If the round trip returns your original text character-for-character, the notation and byte boundaries are correct; if the decoder reports a fatal error at a specific offset, the source is not the UTF-8 you thought it was. For reliable use, start with a short known sample, choose the correct representation, inspect byte boundaries, and preserve the original data before converting an unknown source.
If you're weighing options, XOR Encryption Online Bulk: Process Long UTF-8 Messages covers this in detail.