An SMS does not carry text in the way a web page does. It carries a fixed number of bits, and how many characters fit depends on which of two character sets the message uses. That choice is made from the body, not by you, and it is the single largest thing determining what a message costs.
What are the two encodings?
A compact 7-bit set built for SMS, and a 16-bit Unicode set for everything else.
GSM-7 is the default alphabet defined in the GSM standard, now maintained as 3GPP TS 23.038. It holds the Latin letters, digits, common punctuation, and a small set of European accented characters. Seven bits per character is what lets 160 of them fit in a single message.
UCS-2 is a 16-bit encoding covering the wider Unicode range: emoji, Chinese, Japanese and Korean characters, Cyrillic, Arabic, and the typographic punctuation a word processor inserts without asking. Sixteen bits per character is more than twice the cost, and the capacity falls accordingly.
The standard itself is published only as a PDF, so this page describes it and links it rather than quoting it.
How is the encoding chosen?
By inspection of the whole body, with no mixing. Bird's character limits guide states the rule:
- If every character belongs to the GSM-7 alphabet (the standard 7-bit character set defined by GSM 03.38), the message uses GSM-7 encoding.
- If any single character falls outside GSM-7, the entire message switches to UCS-2 (16-bit Unicode encoding).
and then the consequence, which is the part worth internalising:
Bird does not mix encodings within a message. One emoji, CJK character, or curly quote converts the whole body to UCS-2.
That is not a Bird decision. The encoding is a property of the message as the network carries it, so a single out-of-set character has to change the whole thing.
How much does that cost?
Well over half your capacity, and more once the message splits.
| Encoding | Single segment | Per segment when split |
|---|---|---|
| GSM-7 | 160 characters | 153 characters |
| UCS-2 | 70 characters | 67 characters |
The second column is lower than the first because a multipart message reserves a few bytes in each part for a reassembly header, so the parts can be put back together in order. What is a concatenated SMS covers that mechanism, and what is an SMS segment covers what you are billed for.
The practical shape of it: a 155-character message in plain ASCII is one segment. Paste in a typographic apostrophe from a word processor and the same message becomes UCS-2, needs 70 characters per part, and costs three segments instead of one.
Which characters catch people out?
The ones that do not look like special characters.
- Curly quotes and apostrophes. A word processor or a CMS silently converts
'to’, and the second is not in GSM-7. - The en dash and em dash. Both outside the set; the plain hyphen is inside it.
- The ellipsis character. Three full stops are GSM-7; the single
…glyph is not. - Emoji. Always UCS-2, and often more than one character's worth.
- Accented letters beyond the small GSM-7 set. Some are in it, many are not, and the boundary is not intuitive.
A handful of GSM-7 characters cost two slots rather than one, because they live in an extension table rather than the base alphabet: ^, {, }, \, [, ], ~, | and the euro sign. They do not force UCS-2, but they do consume capacity twice over.
Can I avoid the switch?
Sometimes, by substituting rather than by rewriting.
Where the out-of-set character has a GSM-7 equivalent that means the same thing, substituting it keeps the message in the cheaper encoding without changing what it says: a typographic apostrophe becomes a straight one, an em dash becomes a hyphen, an ellipsis becomes three dots. Bird does this automatically, and what is smart encoding covers what it substitutes and where it stops.
What no substitution can fix is content that genuinely needs the wider set. A message in Arabic or Japanese is UCS-2 by nature, and the 70-character budget is the real constraint to design around rather than an inefficiency to remove.