SMS Character Limits & Segment Counting
SMS messages have strict character limits that affect both cost and deliverability. A single SMS can hold 160 characters using GSM-7 encoding (standard Latin alphabet), but only 70 characters if you include emojis or non-Latin characters (Unicode). Longer messages are split into segments, with each segment counting as a separate SMS for billing purposes. This reference covers standard SMS limits, Unicode handling, and carrier-specific maximums.
When You Need This Table
- Building SMS notifications or marketing campaigns
- Calculating message costs based on segment count
- Deciding whether to use emojis (which trigger Unicode encoding)
- Integrating with SMS APIs like Twilio, AWS SNS, or Vonage
- Optimizing message length to reduce delivery costs
SMS & MMS Limits by Type
| Message Type | Characters | Segments | Notes |
|---|---|---|---|
| Standard SMS (GSM-7) | 160 | 1 | Latin alphabet, numbers, basic symbols |
| Long SMS (GSM-7) | 153 | Per segment | 7 chars reserved for concatenation header |
| Unicode SMS | 70 | 1 | Emojis, non-Latin scripts (Chinese, Arabic, etc.) |
| Long Unicode SMS | 67 | Per segment | 3 chars reserved for concatenation header |
| MMS Subject | 40 | N/A | Subject line for multimedia messages |
| MMS Body | 1,600 | N/A | Varies by carrier; 1,600 is common max |
| RCS Message | 8,000 | N/A | Rich Communication Services (Android) |
| iMessage | Unlimited* | N/A | Falls back to SMS if recipient not on iMessage |
*iMessage has no character limit but falls back to SMS (with limits) for non-Apple recipients.
Carrier & API Limits
| Provider | Single SMS | Max Segments | Max Characters |
|---|---|---|---|
| Twilio | 160 GSM / 70 Unicode | 10 | 1,600 |
| AWS SNS | 160 GSM / 70 Unicode | 6 | 918 |
| Vonage (Nexmo) | 160 GSM / 70 Unicode | 7 | 1,071 |
| MessageBird | 160 GSM / 70 Unicode | 9 | 1,377 |
| Plivo | 160 GSM / 70 Unicode | 10 | 1,600 |
GSM-7 vs Unicode
- GSM-7: 160 chars, standard letters, numbers, basic punctuation
- Unicode: 70 chars, required for emojis and non-Latin scripts
- One emoji forces entire message to Unicode encoding
- Some "special" GSM characters count as 2 (€, [, ], etc.)
Cost Optimization Tips
- Avoid emojis in transactional SMS to stay in GSM-7
- Keep messages under 160 chars for single-segment billing
- Use URL shorteners to save characters
- Test encoding before sending campaigns
Understanding SMS Segmentation
When your message exceeds the single-SMS limit (160 GSM-7 or 70 Unicode characters), it gets split into multiple segments. Each segment reserves characters for a concatenation header that tells the recipient's phone how to reassemble the message. This reduces usable characters to 153 (GSM-7) or 67 (Unicode) per segment.
For example, a 161-character GSM-7 message becomes 2 segments (costing twice as much), while a 306-character message becomes 2 segments as well. Understanding this threshold helps you optimize message length — sometimes removing 2 characters saves an entire segment's cost.
Modern messaging alternatives like RCS (Rich Communication Services) and iMessage don't have the same strict limits, but they only work when both sender and recipient support them. For universal delivery, plan for standard SMS constraints.
How to Calculate SMS Segments
Calculating SMS segments involves understanding both encoding type and message length. For standard GSM-7 messages, divide your total character count by 160 to determine segments. Unicode messages require division by 70. However, long messages add 7 (for GSM-7) or 3 (for Unicode) characters per segment for concatenation headers. For example, a 200-character GSM-7 message uses (200 - 7) / 153 = 1.24 segments, meaning it splits into 2 segments. Carrier APIs often provide automated segment calculators, but manual verification is recommended for critical messages. Always test with actual carrier systems, as some platforms apply different rounding rules.
Best Practices for Staying Under SMS Limits
- Using GSM-7 characters where possible (avoid emojis and non-Latin scripts unless necessary)
- Implementing message truncation alerts in your application logic
- Using abbreviations for frequent terms (e.g., "meet" → "mtg")
- Testing with carrier-specific APIs to verify segment counts
- For Unicode messages, consider breaking long content into multiple pre-formatted segments manually rather than relying on automatic concatenation
- When working with Twilio or AWS SNS, configure your platform to reject messages exceeding carrier maximums before sending
- For international campaigns, account for language-specific character encoding requirements, as some languages require Unicode by default
Common SMS Limit Issues and Solutions
Common problems include unexpected segmentation due to Unicode characters, higher-than-expected costs from multi-segment messages, and failed deliveries caused by carrier-specific limits. To resolve these:
- Use character encoding detectors in your backend to identify Unicode content before sending
- Implement cost estimation formulas using carrier-specific maximums (e.g., Twilio's 1,600 character limit vs AWS SNS's 918 limit)
- Monitor delivery reports to identify carrier-specific failures
- For platforms like Plivo or Vonage, leverage their message validation endpoints to pre-check content before sending
- Always maintain a buffer of 10-15% below carrier limits to account for header data and encoding variations