Unicode Binary

Unicode vs ASCII — The Big Picture

When I first learned binary, I assumed ASCII was all there was. Then I tried to encode Chinese characters and ran straight into the wall — ASCII only handles 128 characters. Unicode solved this by using code points: each character gets a numeric ID, regardless of platform or language. The clever part is how those numbers get turned into binary, and that is where UTF-8, UTF-16, and UTF-32 come in. Each scheme represents the same code point differently at the binary level.

A Unicode code point is a number between 0 and 1,114,111 (0x10FFFF). That number must be converted to binary before a computer can store or transmit it:

• U+0041 ('A') = 65 in decimal = 1000001 in binary
• U+4E2D ('中') = 20,013 in decimal = 100111000101101 in binary
• U+1F600 (emoji 😀) = 128,512 in decimal = 11111011000000000 in binary

The challenge is: how many bits do you use? ASCII fits in 7 bits, '中' needs 15 bits, and the emoji needs 17 bits. Different encoding schemes answer this question differently. You can use our binary to English tool to convert simple ASCII binary, but for Unicode characters the encoding scheme matters.

Binary Representation by Code Point Range

Unicode divides its space into 17 planes, each with 65,536 code points. The bits needed vary by plane:

• Plane 0 (BMP): U+0000 to U+FFFF — 16 bits max. Covers most common scripts (Latin, CJK, Arabic, etc.)
• Plane 1 (SMP): U+10000 to U+1FFFF — 17-20 bits. Emoji, ancient scripts, musical notation
• Planes 2-16: U+20000 to U+10FFFF — up to 21 bits. Rare CJK ideographs and reserved space

UTF-32 uses exactly 4 bytes (32 bits) for every character, regardless of code point:

• 'A' (U+0041) = 00000000 00000000 00000000 01000001
• '中' (U+4E2D) = 00000000 00000000 01001110 00101101
• 😀 (U+1F600) = 00000000 00000001 11110110 00000000

UTF-32 is wasteful for most text (4x larger than ASCII for English), but it makes indexing trivial — character N always starts at byte 4×N. I use UTF-32 only when I need random access into a Unicode string without decoding.

UTF-16 is the default encoding in Java, JavaScript (internally), and Windows. It uses either 2 or 4 bytes per code point:

• BMP characters (U+0000 to U+FFFF): exactly 2 bytes (16 bits)
• Supplementary characters (U+10000+): 4 bytes using surrogate pairs

For example, 'A' is 00000000 01000001 in UTF-16BE (big-endian), while 😀 is split into two 16-bit surrogates: 11011000 00111101 11011110 00000000 (a high surrogate 0xD83D and a low surrogate 0xDE00). This surrogate mechanism is why you sometimes see "broken" emoji in old software — it failed to interpret the pair correctly.

UTF-8 is the most popular encoding on the web, and for good reason. It uses 1 to 4 bytes per character and is fully backward-compatible with ASCII:

• 1 byte: U+0000 to U+007F (ASCII) — 0xxxxxxx
• 2 bytes: U+0080 to U+07FF — 110xxxxx 10xxxxxx
• 3 bytes: U+0800 to U+FFFF — 1110xxxx 10xxxxxx 10xxxxxx
• 4 bytes: U+10000 to U+10FFFF — 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

For English text, UTF-8 is identical to ASCII — no bloat. This is why it won the encoding war. See our UTF-8 binary guide for a deep dive into how the leading byte markers and continuation bytes work at the bit level.

Here is how each encoding represents the same three characters:

• 'A' (U+0041) — UTF-8: 1 byte, UTF-16: 2 bytes, UTF-32: 4 bytes
• '中' (U+4E2D) — UTF-8: 3 bytes, UTF-16: 2 bytes, UTF-32: 4 bytes
• 😀 (U+1F600) — UTF-8: 4 bytes, UTF-16: 4 bytes (surrogate pair), UTF-32: 4 bytes

The file size implications are significant. A 1,000-character English page is ~1KB in UTF-8 but 4KB in UTF-32. The same page in Chinese might be 3KB in UTF-8 but still 4KB in UTF-32 — and 2KB in UTF-16. Choosing the right encoding is a storage and bandwidth decision.

The BOM is a special Unicode character (U+FEFF) placed at the beginning of a text stream to signal byte order:

• UTF-8 BOM: 11101111 10111011 10111111 (EF BB BF) — not required since UTF-8 has no endianness, but some Windows tools add it
• UTF-16BE BOM: 11111110 11111111 (FE FF)
• UTF-16LE BOM: 11111111 11111110 (FF FE)
• UTF-32BE BOM: 00000000 00000000 11111110 11111111 (00 00 FE FF)
• UTF-32LE BOM: 11111111 11111110 00000000 00000000 (FF FE 00 00)

In my experience, the UTF-8 BOM causes more problems than it solves — Unix tools like sed and awk choke on it. I always strip the BOM unless I am targeting Windows-only applications.

When you use a binary translation tool, knowing the encoding is half the battle. Our binary decoder handles 8-bit ASCII bytes, but for Unicode, you need to know which encoding produced the binary sequence. If you see 11100100 10111000 10101101, that is the UTF-8 encoding of '中' — not three separate characters but one. This distinction is critical when translating binary to readable text, especially for multilingual content.