UCS-2 UCS-2 (2-byte Universal Character Set) Unicode
UTF-16's fixed-width predecessor — capped at the Basic Multilingual Plane, with no mechanism to represent characters beyond U+FFFF.
What it is
UCS-2 is a fixed 2-byte-per-character encoding that was Unicode's original intended encoding, back when 16 bits (65,536 possible values) was assumed to be enough to represent every character system that would ever need representing. It has no mechanism for representing characters beyond U+FFFF — no surrogate pairs, no extension mechanism, nothing. When Unicode's scope grew past that ceiling (adding historic scripts, mathematical symbols, and eventually emoji), UCS-2 couldn't be extended in place, which led directly to UTF-16 being created as a surrogate-pair-based superset that could reach further while staying mostly compatible with existing UCS-2 data.
As of 2026, UCS-2 mostly survives in legacy systems and a handful of protocol specifications that predate UTF-16's widespread adoption — most notably classic SMS text encoding, which still uses UCS-2 for non-GSM-alphabet characters.
Byte structure
| Code point range | Bytes used |
|---|---|
| U+0000 – U+FFFF (Basic Multilingual Plane only) | Always exactly 2 bytes |
| U+10000 and above | Not representable — no encoding mechanism exists in UCS-2 for these |
That last row is the entire story of why UCS-2 was retired in favor of UTF-16 — it's not a limitation UTF-16 shares, since UTF-16's surrogate pairs specifically solve this gap.
Why your text is garbled (symptom → cause)
| Symptom | Likely cause |
|---|---|
| Emoji or rare characters silently dropped or replaced entirely | The system is genuinely limited to UCS-2 (common in legacy SMS gateways and old telecom systems) and has no way to represent supplementary-plane characters at all |
| SMS message unexpectedly splits into multiple message segments | Classic SMS uses a 7-bit GSM alphabet for a limited character set, but falls back to UCS-2 (2 bytes/character) the moment any character outside that alphabet appears — this roughly halves the character count that fits in a single message segment, which is why "just one emoji" can shrink your SMS character limit dramatically |
| Legacy database column truncates or rejects modern Unicode text | Old schema/driver still assumes UCS-2-equivalent 2-byte-max character width, inherited from an era before UTF-16 surrogate pairs were common practice |
Compatibility & gotchas
- SMS is the most common place UCS-2 still matters practically. Standard SMS uses either the 7-bit GSM 03.38 alphabet (160 characters per segment) or, if any character falls outside that alphabet, switches the entire message to UCS-2 encoding (70 characters per segment) — this is why adding a single emoji or certain accented characters to a text message can sharply reduce the character count before it splits into multiple message parts.
- Cannot represent most emoji at all, strictly speaking, since UCS-2 has no surrogate-pair mechanism — systems still genuinely limited to UCS-2 (rather than UTF-16) either drop such characters, substitute a placeholder, or reject the input entirely.
- Often confused with UTF-16 in casual conversation and even in some older documentation/API naming — some older Windows and database APIs historically labeled themselves "UCS-2" or "Unicode" when they actually behaved more like UTF-16 (or vice versa), so verifying actual behavior rather than trusting a label is worthwhile with legacy systems.
- Effectively obsolete for new system design — any new system needing 16-bit-unit-based Unicode handling should use UTF-16 (with surrogate pair support) rather than UCS-2, to avoid this exact representability gap.
Fixing it
- SMS character limit surprises: if a message unexpectedly needs to support characters outside the GSM 7-bit alphabet (accented characters, non-Latin scripts, emoji), plan for the reduced 70-character UCS-2 segment size rather than assuming the standard 160-character limit applies.
- Legacy system upgrades: if a system is genuinely limited to UCS-2 and needs to support full Unicode (including emoji), the fix is a proper UTF-16 (or UTF-8) upgrade, not a workaround within UCS-2 itself, since UCS-2 fundamentally cannot represent the needed characters.
- Verifying UCS-2 vs. UTF-16 in an unfamiliar legacy system: test with a character requiring a surrogate pair (most emoji work well for this) — if it's silently dropped, substituted, or causes an error, the system is genuinely UCS-2-limited rather than mislabeled UTF-16.
Comparison
| Encoding | Key difference from UCS-2 |
|---|---|
| UTF-16 | Adds surrogate pairs to reach the full Unicode range beyond U+FFFF — the direct successor built specifically to fix UCS-2's ceiling |
| UTF-8 | Variable width, ASCII-compatible, full Unicode range, dominant for modern storage/transmission |
| UTF-32 | Fixed 4 bytes covering the full Unicode range with no surrogate mechanism needed, at a higher storage cost |
FAQ
Is UCS-2 the same as UTF-16?
No, though they're closely related and easy to confuse. UCS-2 is fixed 2-byte-only and cannot represent anything beyond U+FFFF. UTF-16 extends the same basic approach with surrogate pairs specifically to reach the full Unicode range, including most emoji and supplementary scripts.
Why does adding an emoji to a text message reduce how many characters I can send?
Standard SMS uses a compact 7-bit alphabet (160 characters per segment) for common characters, but falls back to UCS-2 (2 bytes per character, 70 characters per segment) the moment any character outside that alphabet appears — including most emoji. This roughly halves your per-segment character budget.
Should I ever choose UCS-2 for a new system?
No — it's effectively obsolete for new design. Any system needing 16-bit-unit Unicode representation should use UTF-16 instead, which provides the same basic 2-byte-per-unit approach while actually supporting the full Unicode range via surrogate pairs.
Fun fact
The original Unicode 1.0 specification (1991) was explicitly designed around the assumption that 16 bits would be sufficient forever — UCS-2 is essentially a direct implementation of that assumption. It took less than a decade for Unicode's actual character repertoire to outgrow that ceiling, making UCS-2 one of the shorter-lived "permanent" technical assumptions in modern computing history.