ASCII: 128 characters, one byte each, no accents at all
ASCII, standardized in 1963, uses exactly 7 bits per character — 128 possible values, covering unaccented English letters, digits, and basic punctuation. It has no representation for é, ñ, €, or any character outside that original 128. Almost nothing in modern computing is "pure ASCII only" anymore, but ASCII is the common subset every other encoding on this page still agrees with for basic Latin — which is exactly why English-only text rarely reveals encoding bugs.
UTF-8: variable width, 1 to 4 bytes, backward-compatible with ASCII
UTF-8 represents each character using 1 to 4 bytes depending on which character it is. Plain English letters, digits, and basic punctuation take exactly 1 byte — identical to ASCII. Accented Latin letters (é, ñ, ü) take 2 bytes. Most other scripts and symbols take 2-3 bytes. Rarer characters and emoji take 4 bytes. This design, plus full ASCII backward compatibility, is why UTF-8 became the dominant encoding for the web and most modern software.
UTF-16: fixed-ish width, 2 or 4 bytes, no ASCII compatibility
UTF-16 represents most common characters (including basic Latin letters) using 2 bytes each, with less common characters requiring 4 bytes via surrogate pairs. Critically, UTF-16 is not byte-compatible with ASCII — even the letter "A" takes 2 bytes in UTF-16 versus 1 byte in ASCII and UTF-8. UTF-16 is the internal string format for Windows, Java, and JavaScript's internal string representation, which is why you'll encounter it inside application code even on systems where files and network traffic are UTF-8.
The comparison that actually matters for debugging
| ASCII | UTF-8 | UTF-16 | |
|---|---|---|---|
| Bytes per character | 1 (fixed) | 1-4 (variable) | 2 or 4 |
| Handles é, ñ, ü | No | Yes | Yes |
| Compatible with ASCII files | — | Yes | No |
| Dominant use today | Legacy / protocol-level | Web, most files, databases | Windows internals, Java, JS strings |
Where this actually bites you
A file saved or declared as one encoding and read as another is the root cause behind the mojibake described in our Word-to-website encoding guide, HTML entities guide, and in Unicode explained. The UTF-8/UTF-16 distinction matters most when moving text between a Windows-native tool (which may produce UTF-16-encoded files, sometimes labeled "Unicode" in Windows' own Save As dialogs) and a web or Unix-based system that assumes UTF-8 by default. You can inspect raw byte sequences using our Unicode Inspector.
The practical rule
Default to UTF-8 for anything you create, save, or configure yourself. Only reach for UTF-16 awareness when debugging why a specific Windows-originated file or a JavaScript string-length calculation is behaving unexpectedly.