Smart encoding is a per-send option that replaces characters forcing a message into UCS-2 with their GSM-7 equivalents, before the message goes out. Since UCS-2 more than halves the room in a segment, the saving can be large: a body that was three segments can become one.
It is worth understanding as a rule with a sharp edge rather than a general cleanup, because the times it does nothing are more common than people expect and it does not tell you loudly when it declines.
What does it actually replace?
The characters you did not choose.
The usual triggers for UCS-2 are not deliberate: a word processor turned ' into ’, an em dash arrived with a paste, a form field carried a non-breaking space. Those have GSM-7 equivalents that mean the same thing, so replacing them changes nothing a reader would notice and can halve what the message costs.
What it will not do is fold accents. á does not become a, and that is a deliberate refusal rather than a gap in the table: replacing it would change the word rather than approximate it, which is the wrong trade for anyone writing Spanish or Portuguese.
Worth knowing while you are here, because it decides whether you need this at all: GSM-7 already contains à, ä, å, é, è, ì, ò, ù, ö, ñ and ü, and does not contain á, í or ú. So plenty of accented text is already free.
Why did nothing change on my message?
Almost certainly because the replacement would not have been enough.
Replacement applies only when it brings the whole body into GSM-7. If any character would still be outside it afterwards, Bird sends the body exactly as supplied and replaces nothing at all. There is no partial credit, because there would be no point: one surviving character keeps the entire message in UCS-2, so the replacements would change your text without saving a segment.
That is why a single emoji, one CJK character, or one á cancels the whole thing. A body of otherwise ordinary text with a curly quote and an á in it keeps both, and stays UCS-2.
There is a subtler version that catches people, and it depends on how the text was normalised rather than on what it looks like. An ê typed as a decomposed pair, a plain e followed by a combining accent, is converted to e^. The same ê stored as a single precomposed character is not, and stays UCS-2. Two visually identical strings can therefore behave differently.
What does it not do?
Three things worth being explicit about, because each is a reasonable thing to assume.
- It never truncates. A body over the maximum message length is rejected with a
422rather than being shortened. The cap is measured after replacement, though, so opting in can bring an oversized body under it and turn a rejection into a send. - It does nothing to a body that is already GSM-7. There are no segments to save.
- It does not change what you are billed for beyond the segment count, which is computed from the body as actually sent. If nothing was replaced, you pay for what you wrote.
How do I tell whether it worked?
Read the message back. Both halves of the answer are on it.
text is the body as sent, so comparing it with what you submitted shows you whether anything was replaced. options.smart_encoding reports the setting that applied, rather than what your request happened to say, and segments.encoding tells you the outcome.
The combination to watch for is smart_encoding true and encoding still UCS2. That is the option having been asked for and not having helped, which means something in the body has no GSM-7 equivalent. It is a normal outcome rather than a fault, and the fix is in the copy rather than in the setting.
To see what will happen before you send anything, the SMS segment calculator takes the text and shows the encoding and segment count it produces.
Should I just turn it on for everything?
For transactional copy assembled from templates and user data, generally yes: the characters it replaces are the ones that arrive by accident, and it cannot make a message cost more.
Two caveats. It is off unless you ask for it, per send, so "turn it on" means setting it everywhere you send rather than once. And it is not a substitute for knowing which encoding your copy lands in, because the case it cannot fix, a name or a place with an á in it, is exactly the case that recurs in the same message every day.
Smart encoding has the full replacement table, and SMS character limits and segment counting covers what forces UCS-2 in the first place.