Convert Decimal to UTF-8

Because “decimal to UTF-8” is ambiguous. If your source gave you raw UTF-8 bytes (like Wireshark packet dumps, hexdump -d, or Python .encode('utf-8') output), each decimal is one byte. If your source gave you Unicode code points (like hex(ord(c))), each decimal is one character. The tool would produce different outputs for the same input in each mode, so you pick.

Those four bytes are the UTF-8 encoding of U+1F600 😀. In binary: 11110000 10011111 10011000 10000000. UTF-8’s 4-byte form packs 21 bits: 000 011111 011000 000000 = 0x1F600. The tool’s TextDecoder('utf-8') handles the byte grouping and returns the single character.

When you want the decoder to complain on invalid UTF-8 instead of silently substituting replacement characters. Non-fatal mode (the default) is forgiving – it emits U+FFFD wherever the bytes don’t form valid UTF-8, so you always get some output. Fatal mode throws a specific error, which is what you want when validating that a byte stream is actually well-formed UTF-8.

Bytes mode: 0-255. Code-points mode: 0-1114111 (0x10FFFF, the top of Unicode). Out-of-range values are reported in the breakdown as “out of byte range 0-255” or “out of Unicode range 0-1114111”, without aborting the batch.

Because that’s hex notation, not decimal – mixing bases in a tool called “decimal-to-utf8” would just cause bugs. You get a specific error: “not a decimal number (hex prefix 0x not accepted)”. For hex input, use the hex-to-UTF-8 tool.

The code-points-to-utf8 tool always treats input as Unicode code points. This tool defaults to byte interpretation but has a code-points mode toggle, so both workflows fit in one page. If you always work with code points, the dedicated tool is cleaner; if you mix both, this one is more convenient.

Because that’s not valid UTF-8. 0xC0 (192) is a 2-byte lead byte, and 0xA0 (160) is a valid continuation byte, but the sequence 0xC0 0xA0 would decode to U+0020 (space) – an overlong encoding, explicitly forbidden by RFC 3629 since 2003 as a security issue. The tool substitutes U+FFFD for the illegal sequence.

Yes. U+D800-U+DFFF are reserved as UTF-16 surrogate halves and aren’t valid standalone Unicode code points. The tool flags them in the breakdown with a specific error. If you need to emit lone surrogates (for WTF-8 study or similar), use a tool that explicitly allows them.

Yes – use the UTF-8-to-decimal encoder. The pair is lossless: encode with one tool, decode with this one, and you get back the original bytes. The same round-trip works for code-points mode with the decimal-to-code-points and code-points-to-decimal tools.

Yes. Uses the browser’s native TextDecoder and String.fromCodePoint. No upload, no tracking, no account. Load once and it works offline indefinitely.