Unicode vs ASCII: What's the Difference and Why Does It Matter?

Have you ever pasted text from Word into a web form and seen "“" where a curly quote should be? Or had an app crash because a user typed an emoji? That's a character encoding problem. Understanding ASCII, Unicode, and UTF-8 isn't just trivia — it explains why these bugs happen and how to fix them.

ASCII: 128 Characters and Nothing More

ASCII (American Standard Code for Information Interchange) was created in 1963 for telegraphs and early computers. It maps 128 characters to numbers 0–127:

• 0–31: Control characters (newline, tab, null, bell)
• 32–126: Printable characters (A–Z, a–z, 0–9, punctuation, space)
• 127: Delete

That's it. No accented letters. No Cyrillic. No Arabic. No Chinese. No emoji. When the internet spread globally, ASCII was completely inadequate.

Extended ASCII: The Chaos Years

Computer makers in the 1980s needed characters beyond 128, so they used the 8th bit to define 128 more characters (values 128–255). But with no universal standard, every company defined their own mapping. Windows used CP1252. IBM used CP437. Macs used MacRoman. These incompatible "code pages" meant text from one system looked like garbage on another — the origin of mojibake (文字化け).

Unicode: One Standard to Rule Them All

Unicode, first published in 1991, assigns a unique code point to every character in every writing system ever used — plus emoji, mathematical symbols, Braille, Egyptian hieroglyphs, and more. Current Unicode 15.1 covers 149,813 characters across 161 scripts.

Code points are written as U+XXXX (e.g., U+0041 = A, U+1F600 = 😀). The range U+0000 to U+007F is identical to ASCII — backward compatible by design.

Unicode ≠ UTF-8: The Encoding Question

Unicode is a standard (a table of code points). It doesn't say how to store them in bytes. That's what encodings do:

How UTF-8 Works

UTF-8 uses a variable number of bytes depending on the code point's value:

Why Emoji Are 4 Bytes (And Why That Causes JavaScript Bugs)

JavaScript's String.length counts UTF-16 code units, not characters. For Basic Multilingual Plane characters (U+0000–U+FFFF), one character = one code unit. For emoji and other supplementary characters (U+10000+), one character = two code units (a "surrogate pair"). So:

This is why naively truncating strings at a character count can split a surrogate pair and produce corrupt output. Always use spread or Intl.Segmenter for Unicode-aware string manipulation.

The Mojibake Problem

The "“" problem happens when UTF-8 text is interpreted as Windows-1252. The UTF-8 bytes for a curly left quote (U+201C) are C2 9C 80 — and those bytes, read as Windows-1252, produce “. The fix is always to ensure your database, application, and browser agree on UTF-8 at every layer.

Exploring Character Encodings with ToollyX

The Text to Binary tool shows the exact binary representation of any text character by character. Try typing an emoji and watch the 4-byte UTF-8 representation appear. The URL Encoder shows percent-encoding of Unicode characters — each byte becomes %XX in URLs. And HTML Encoder converts characters to their HTML entity equivalents like ☃ for ☃.