Text measurement scope and encoding
SMS Character Length: Encoding Units and Segment Estimates
Understand GSM-7 and Unicode SMS length, two-unit characters and segment boundaries, with checked examples and clear limits on what a local counter can predict.
SMS character length depends on encoding units, not just the number of visible symbols. Basic GSM-7 text commonly fits 160 units in one segment, while Unicode uses a smaller capacity. A character such as a caret or an emoji can consume two units. Use an SMS-specific estimate and confirm the final payload and route with the messaging provider.
Separate visible characters from encoded units
A plain character counter may count grapheme clusters, Unicode code points or UTF-16 units. Those measurements answer different questions. The local SMS Character Counter displays encoding units separately from its general writing metrics so that a visible-character total is not mistaken for a transmission budget.
For example, a single smiling emoji can appear as one symbol while occupying two UTF-16 units. A combined emoji made from a person, a joining character and a laptop can appear as one symbol but use five units. Removing one visible symbol therefore does not always remove one unit from the SMS estimate.
Account for the GSM extension table
Ordinary letters such as A use one GSM-7 septet in the default alphabet. Extension characters such as ^, braces and the euro sign use an escape plus the character code, consuming two septets. Twilio’s GSM-7 reference explains the distinction.
The text ^€ contains two visible characters but uses four GSM-7 units. Eighty carets use 160 units and fit the single-segment capacity in the default model. Eighty-one carets use 162 units and require multipart segmentation even though the visible-character count is far below 160.
Count the exact text supplied
A precomposed é is part of the default GSM-7 alphabet. The visually similar sequence e followed by a combining acute accent contains a different set of code points and selects the Unicode model. The SMS calculation must inspect that original sequence rather than silently normalizing it into the precomposed character.
The tool does not replace smart quotes or normalize accents on your behalf. If your provider applies its own text substitutions, the submitted or transmitted payload may differ from what you pasted here. Review that actual payload before comparing provider segment records with a local estimate.
Read the boundary examples
| Input | Encoding units | Default-model segments |
|---|---|---|
| 160 ordinary A characters | 160 GSM-7 units | 1 |
| 161 ordinary A characters | 161 GSM-7 units | 2 |
| 153 carets | 306 GSM-7 units | 3 |
| 35 smiling emoji | 70 UTF-16 units | 1 |
| 67 smiling emoji | 134 UTF-16 units | 3 |
These examples use the model documented on the tool page. The carets and emoji remain indivisible two-unit tokens at a segment boundary. Empty text is shown as zero segments; it is not a request to send an empty SMS.
Understand why simple division can undercount
Once a message becomes multipart, the default capacities are 153 GSM-7 units or 67 UTF-16 units per segment. If every token uses two units, a 153-unit segment can hold only 152 used units without splitting a token. The remaining one-unit space cannot hold another caret.
For 153 carets, the used-unit distribution is 152, 152 and 2. For 67 smiling emoji, it is 66, 66 and 2 under the code-point packing model. Simply dividing total units by the capacity and rounding up misses these boundary constraints. The tool’s gauge reports the unused capacity of the final segment, not unused gaps in earlier segments.
Keep provider-specific rules separate
Twilio’s length documentation describes the usual 160/153 and 70/67 capacities and a 152/66 multipart exception for US and Canada toll-free routes. Other header choices, national-language shift tables or provider behavior can require a different model.
The local counter does not know your route, billing plan, custom headers or delivery result. It estimates the stated default model and preserves the supplied text. A successful calculation is therefore not a guarantee of a particular invoice amount or delivery outcome.
Check the final message after edits
Paste the complete message, including links, line breaks and any text added by your sending system. Inspect encoding, total units and segment count. After replacing a symbol or shortening a phrase, recalculate the full message rather than subtracting visible characters from an earlier estimate.
Finally, compare the submitted payload and provider-reported segmentation in a controlled test appropriate to your sending workflow. Keep that evidence with the message version. This separates a content edit, a provider transformation and a route-specific capacity difference when their results do not match.


