DevLab

UTF-8 vs. UTF-16

Two Unicode encodings compared — why the web chose UTF-8 and when UTF-16 still makes sense.

A

UTF-8

Pros
  • ASCII-compatible — every ASCII file is valid UTF-8
  • Compact for English and Latin-script text (1 byte per character)
  • No byte-order issues (no BOM needed)
  • The web standard — used by 98% of websites
Cons
  • Variable width (1-4 bytes) makes random access by character index O(n)
  • CJK characters use 3 bytes (vs 2 in UTF-16)
  • String length in bytes does not equal character count
  • Emoji are 4 bytes
BEST FOR
Web pages, APIs, JSON, configuration files, databases, log files, any new project
B

UTF-16

Pros
  • CJK characters use 2 bytes (more compact than UTF-8 for CJK-heavy text)
  • Used internally by JavaScript, Java, C#, and Windows
  • Most characters in the Basic Multilingual Plane are 2 bytes (fixed width for common text)
  • Faster character-level indexing for BMP text
Cons
  • Not ASCII-compatible — even "A" uses 2 bytes
  • Byte order matters — requires BOM or convention (BE vs LE)
  • Emoji and rare characters still need surrogate pairs (4 bytes)
  • Larger than UTF-8 for ASCII-heavy content
BEST FOR
Internal string representation in JavaScript/Java/C# (you do not choose this — the runtime does), Windows API interop, processing text that is predominantly CJK
Verdict

Use UTF-8 for storage, transmission, and interchange — it is the universal standard and is more compact for most content. UTF-16 is an implementation detail of JavaScript, Java, and Windows internals — you rarely choose it directly. When you encounter UTF-16 (e.g. reading a Windows-generated CSV), convert to UTF-8 at the boundary.

Try these tools

More Comparisons