SMS looks simple on the surface — 160 characters, hit send — but the underlying encoding and segmentation rules directly affect message length, billing, and campaign performance. This guide explains GSM-7, the extended table, UCS-2/Unicode, User Data Headers (UDH), the 160/153 and 70/67 limits, and the operational decisions marketers must make when crafting multilingual or emoji-rich campaigns. It focuses on practical, actionable advice and testing frameworks you can apply today. ### Why this matters - Encoding decisions change how many segments your message consumes, and providers bill per segment [1] [3]. - One non-GSM character can force a full message into UCS-2, multiplying segments and cost [1] [2]. - Proper pre-send checks and A/B testing protect both your budget and user experience [4].
## Core concepts: payload, encoding, and segments - SMS uses a 140-byte user data payload. How those bytes are used depends on encoding [1]. - GSM-7: a 7-bit encoding designed for many Latin-alphabet characters. A single-segment GSM-7 message fits 160 characters [1]. - GSM extended table: certain characters (pipe |, caret ^, euro €, curly braces {}, backslash \\, tilde ~, square brackets []) require an escape and consume two character positions when using GSM encoding [3]. - UCS-2/Unicode: uses 16 bits per code point. A single-segment UCS-2 message fits 70 characters [2]. - User Data Header (UDH): concatenation and reassembly metadata stored in a header reduces available characters per segment — 153 GSM-7 or 67 UCS-2 per multipart segment [2].
These details determine the familiar limits: 160/153 for GSM-7 messages (single vs multipart) and 70/67 for UCS-2 (single vs multipart) [1] [2]. ## Encoding comparison table | Encoding | Single-segment limit | Multipart (per-part) limit | Notes | |---|---:|---:|---| | GSM-7 | 160 characters | 153 characters | 7-bit encoding; most common Latin characters; 140-byte payload [1] [2]. | | GSM-7 (extended) | 160 characters (some chars count double) | 153 per part (extended chars consume two positions) | Escape characters including the vertical bar, caret, euro sign, braces, brackets, tilde, and backslash consume two positions each [3]. | | UCS-2 / Unicode | 70 characters | 67 characters | 16-bit code points; any non-GSM character (including most emojis) triggers UCS-2; multipart parts carry UDH overhead [2].
| ## Practical, quantified examples - Example 1: 160 GSM-7 characters = 1 segment. - Example 2: 161 GSM-7 characters → 2 segments at 153 chars per part; total capacity 306 characters across two parts (153 + 153) [1]. - Example 3: 152 GSM-7-compatible characters + 1 emoji = entire message encoded as UCS-2 and may expand to 3 segments (67 + 67 + 67 = 201 UCS-2 chars) depending on length, because the emoji forces UCS-2 and reduces per-part capacity [2] [4]. - Example 4: A 200-character GSM-7 message normally takes 2 segments; insert one Unicode character and that same message can balloon to 3 UCS-2 segments, increasing cost and size [4]. These examples highlight the nonlinear cost jumps that happen when an otherwise GSM-7 message encounters a single non-GSM character [1] [2] [4].
## User Data Header (UDH) and concatenation UDH contains metadata used to stitch multipart messages back together on the handset. Because UDH consumes payload space, your per-part capacity drops to 153 characters for GSM-7 and 67 for UCS-2 in concatenated messages [2]. Providers set these limits consistently because the UDH bytes live inside the same 140-byte payload [1] [2]. Actionable point: treat the multipart per-part limits (153 and 67) as your working limits when you expect concatenation. ## Copy-paste hazards and input sanitation - Pasting text from web pages, word processors, or chat apps can introduce non-GSM characters such as smart quotes, non-breaking spaces, and emojis that silently flip encoding to UCS-2 [1] [4]. - The result is a much shorter character budget (70 vs 160) and higher segment counts.
Mitigation checklist: - Preflight text through an encoding validator that flags non-GSM characters [4]. - Strip or normalize smart quotes, long dashes, and non-breaking spaces before campaign send. - Provide a message editor character counter that indicates both characters and estimated segments in real time. ## Multilingual tradeoffs — intentional budgeting and testing Multilingual messaging often requires Unicode; that is normal and appropriate. Don’t treat Unicode as a mistake — treat it as a planning variable. Considerations: - If your campaign uses languages requiring diacritics or non-Latin scripts, encode as UCS-2 and budget for 67-character multipart segments [2].
- If mixed-language audiences exist, evaluate sending separate localized messages rather than a one-size-fits-all Unicode message populated with GSM-compatible transliterations. - Test per-language segment usage and cost before full-scale sends; measure conversion and opt-out impacts separately. Recommendation: plan for higher per-message segment usage when you intentionally target languages that require Unicode. Don't avoid correctness to save a few cents; instead, factor segment costs into your ROI model and test [1] [2]. ## When to use MMS or RCS instead Use MMS or RCS when your message requires rich media, long copy, or guaranteed presentation beyond what SMS can deliver cost-effectively. - Use MMS when an image or a longer multimedia experience is essential and your target devices and carriers support it [4].
- Use RCS where available when rich content and interactivity are more important than universal SMS reach [4]. Providers often recommend moving to MMS/RCS when your messages routinely exceed 320 characters for deliverability and user experience reasons [1] [4]. ## Cost and billing: why segments matter SMS providers bill per message segment, not per logical message. That means a single logical message can generate multiple billed segments when it exceeds the single-segment limit or when encoding switches to UCS-2 [1] [3] [4]. Formula (generic): - Billed segments = ceil(message bytes / per-segment payload), where per-segment payload depends on encoding and UDH. - Cost per delivered message = billed segments × provider segment price.
(Use your provider's per-segment rate.) Hypothetical example (for illustration only): - If your provider charge is $0.01 per segment (hypothetical), a 160-character GSM-7 message costs $0.01 (1 segment). A 161-character GSM-7 message costs $0.02 (2 segments) [1]. - The same 161-character message containing a Unicode emoji might become 3 UCS-2 segments and cost $0.03 (hypothetical), because UCS-2 reduces per-part capacity and more parts are required [2] [4]. Always plug your real provider pricing into these formulas. ## KPI connections: segments → cost per delivered message and business metrics Track these KPIs together to understand tradeoffs and ROI: - Segments per delivered message: average number of billed segments per delivered message. - Cost per delivered message = average segments per delivered × cost per segment (provider rate).
- Cost per conversion = cost per delivered × (delivered / conversions) = cost per segment × segments per delivered × (delivered / conversions). - Click-through rate (CTR): clicks ÷ delivered; longer messages can affect CTR positively or negatively depending on content quality. - Opt-out rate: opt-outs ÷ delivered; longer or poorly localized messages can increase opt-outs. - Delivery rate: delivered ÷ sent; compare it across variants to catch operational differences, especially when testing long multipart sends. Practical KPI example (hypothetical math): - Average segments per delivered = 1.35. - Provider rate = $0.01 per segment (hypothetical). - Cost per delivered = 1.35 × $0.01 = $0.0135. - If conversion rate is 2% (campaign measured), then cost per conversion = $0.0135 / 0.02 = $0.675 per conversion.
Use your actual provider unit cost and measured conversion rate; this example only demonstrates how segments multiply into costs. ## Actionable tips for writers and marketers - Keep core transactional copy concise and within single-segment safe limits where possible (<=160 GSM-7 / <=70 UCS-2) for predictable cost and UX [1] [2]. - Use real-time character and segment counters in your campaign composer that show both GSM-7 and UCS-2 behavior. - Avoid risky characters in transactional templates (emojis, smart quotes) unless intentionally used and budgeted for [3] [4]. - Localize by audience and consider language-specific sends rather than mixing languages inside a single message when it inflates encoding. - Implement server-side preflight validation to detect and normalize problematic characters before sends [4].
- If you need longer copy or rich media, prefer MMS or RCS rather than forcing long concatenated SMS chains [1] [4]. ## Pre-send checklist (practical) - Validate encoding: run message text through an encoding checker to detect non-GSM characters. - Check segment count: confirm es