Unicode Decoder

This tool supports \uXXXX (BMP), \UXXXXXXXX (full Unicode), &#DDDD; (decimal HTML entity), &#xHHHH; (hex HTML entity), and U+XXXX (code point notation) for decoding.

UTF-8 encodes each Unicode code point using 1 to 4 bytes. ASCII characters (U+0000 to U+007F) use 1 byte, Latin and other common characters use 2 bytes, most CJK characters use 3 bytes, and emoji and rare characters use 4 bytes.

\uXXXX uses 4 hex digits and can represent characters in the Basic Multilingual Plane (U+0000 to U+FFFF). \UXXXXXXXX uses 8 hex digits and can represent any Unicode character including those beyond the BMP.

These are signs of mojibake: UTF-8 bytes were decoded as Windows-1252/Latin-1. "é" means the two UTF-8 bytes of "é" (0xC3 0xA9) were shown as two separate characters. Use the Fix Garbled Text mode to repair it. "�" is U+FFFD, the replacement character produced when bytes were already invalid — that information is lost and cannot be recovered.

UTF-8 encodes characters in 1–4 bytes and is fully ASCII-compatible, which makes it the default for the web, JSON, and most APIs. UTF-16 encodes characters in 2 or 4 bytes (using surrogate pairs for characters beyond U+FFFF) and is used internally by JavaScript, Java, and Windows. For most text on the web, UTF-8 is smaller and safer.

A code point is a number assigned to a character in the Unicode standard (U+00E9 for e-acute); a code unit is the storage unit an encoding uses. UTF-8 code units are 8-bit bytes - U+00E9 takes two - while UTF-16 code units are 16-bit, and characters beyond U+FFFF need two of them (a surrogate pair). JavaScript strings are UTF-16, so 'hello'.length is 5 but an emoji's .length is 2.

The same visible character can have multiple byte sequences: e-acute as one precomposed character (NFC) or e plus a combining accent (NFD). NFC composes, NFD decomposes, and NFKC/NFKD additionally fold compatibility characters (full-width forms, ligatures). Comparing or hashing user input without normalizing first is a classic source of duplicate accounts and failed lookups - fi ligature vs f+i.

The byte order mark is U+FEFF encoded at the start of a stream (EF BB BF in UTF-8) to signal the encoding. Editors usually hide it, but downstream it becomes an invisible first character: a CSV header gains a phantom key, JSON parsing fails on the stray token, and PHP sessions emit it before headers. UTF-8 needs no BOM since it has no byte-order ambiguity - save without it.