A business writes a 150-character appointment reminder, adds one emoji to make it friendlier, and discovers that the message is now billed as three SMS segments. The dashboard is not necessarily making a mistake. The visible length of a text message and the amount of data sent across a mobile network are not the same thing.
The familiar idea of a 160-character SMS character limit applies only under particular encoding conditions. Emoji, non-Latin scripts, decorative symbols, and even punctuation copied from a word processor can change the encoding used for the entire message. That can reduce the capacity of a single segment from 160 characters to 70.
This distinction matters to developers, marketers, banks, health services, logistics companies, and any organization sending messages at scale. It affects cost estimates, message previews, delivery testing, and sometimes whether the most important part of a notification arrives in the first segment.
An SMS segment carries 140 bytes of message data. How many characters fit into those bytes depends on the character encoding.
Messages that use the GSM-7 character set can normally contain up to 160 characters in one segment. GSM-7 covers the Latin alphabet, digits, and a limited collection of punctuation and special characters commonly used in basic text messages.
If the message contains a character outside that set, many messaging providers switch the entire message to the Unicode encoding commonly labelled UCS-2. A single segment then holds only 70 characters.
Longer messages are divided into multiple segments. Part of each segment is used for the header that tells the receiving device how to put the parts back together, so the usable limits fall again.
These are standard working limits, but routes and providers can have exceptions. Messaging providers therefore recommend checking the encoding and segment count for the final message rather than relying on a general word or character counter.
The encoding change is easy to miss because the triggering character may look ordinary. Compare these two lines:
Your order is ready – reply YES
Your order is ready — reply YES
 
The first line uses a standard hyphen. The second uses an em dash. That typographic improvement can be enough to move a message outside GSM-7. Curly quotation marks copied from a document editor can cause the same problem.
Emoji are the most recognizable trigger, but they are not the only one. Currency marks, mathematical characters, decorative dividers, arrows, accented letters, non-breaking spaces, and other Unicode text symbols may also affect encoding. Some characters are part of the GSM-7 extension table and consume more space than a basic GSM-7 character, while others trigger Unicode encoding for the complete message.
This is why a counter in a content-management system can be misleading. It may report that the text contains fewer than 160 visible characters without knowing how an SMS gateway will encode them.
Counting emoji introduces another layer of complexity. What a reader sees as one symbol is not always stored as one Unicode code point.
A base emoji can be followed by a variation selector that requests emoji-style presentation. A skin-tone modifier can add another code point. Some family, profession, and relationship emoji use a zero-width joiner to combine several components into one displayed glyph.
The Unicode emoji specification explicitly distinguishes between emoji characters and emoji sequences. A supported sequence may appear as one image on screen even though it contains several encoded elements. On a system without the matching combined glyph, the same sequence may display as separate symbols.
As a result, neither visual inspection nor a simple programming-language string length is a reliable SMS segment calculator. An application may count UTF-16 code units, Unicode code points, or user-perceived grapheme clusters, while the messaging provider applies the encoding rules of the delivery channel.
For production messages, the useful measurement is not simply “How many things can I see?” It is “Which encoding will the gateway use, and how many SMS segments will it send?”
Text faces show why exact-message testing matters. A simple Western emoticon such as 🙂 may remain within GSM-7. Japanese-style kaomoji often combine characters from several scripts and symbol ranges:un
(＾▽＾)
¯_(ツ)_/¯
(╯°□°)╯︵ ┻━┻
 
These expressions are valuable precisely because their brackets, eyes, gestures, and spacing carry meaning. Collections of kaomoji examples can therefore provide useful test strings for a messaging interface, but each final string must be checked rather than treated as one generic category.
Not every text face has the same encoding behavior. The first example contains full-width characters. The second includes Japanese katakana. The third combines several symbols. Removing one “unusual” character might reduce a segment count, but it could also damage the expression or change its tone.
That creates a product decision rather than a purely technical one. For a high-volume one-time-password message, compact GSM-7 text may be the priority. For a community notification or consumer campaign, the extra warmth or clarity provided by a symbol may justify another segment. The correct choice depends on message purpose, audience, route, and cost.
When a GSM-7 message exceeds 160 characters, it is normally divided into chunks of 153 characters. A Unicode message longer than 70 characters is divided into chunks commonly holding 67 characters. The reduction leaves room for a user data header containing the information required to reassemble the message.
The recipient’s phone will usually display the parts as one continuous message. Behind the interface, however, each segment travels separately and is commonly billed separately. At scale, a change from one segment to two can nearly double the transport cost of a campaign even when the message looks only slightly longer.
Segmentation can also complicate delivery diagnostics. Parts can be delayed or, on unreliable routes, fail independently. The receiving device and network must reassemble them in the correct order. This does not mean every multipart message is unreliable, but it gives teams a reason to keep time-sensitive instructions concise and to monitor delivery at the segment level.
Dynamic content makes the issue harder. A template may fit into one segment during review but exceed the boundary when it receives a long customer name, order number, location, or tracking link. Testing only the shortest example produces an unrealistic cost estimate.
The GSM-7 and UCS-2 limits describe SMS. Internet-based services such as WhatsApp and Signal use different transport systems, so they do not bill ordinary messages according to GSM SMS segments. RCS also supports Unicode differently from traditional SMS.
The distinction still matters in products that use multiple channels. A rich message may fall back to SMS when data service, device support, or routing conditions require it. Content that appears comfortably within the limits of an app can become a multipart message after fallback.
Display behavior also remains relevant outside SMS. Fonts, operating systems, app versions, and Unicode support can change whether an emoji sequence appears as one glyph, several symbols, or missing-character boxes. Channel-aware previewing is safer than assuming that one browser screenshot represents every recipient’s experience.
Teams do not need to remove all expressive characters from their messages. They need a workflow that measures the final content correctly.
For developers, this check belongs in the messaging pipeline rather than at the end of a marketing review. A useful preview should report at least the detected encoding, the number of segments, and which character caused a switch away from GSM-7.
Emoji, kaomoji, and Unicode symbols can make a short message warmer, clearer, or easier to recognize. The technical mistake is not using them. It is assuming that every visible character occupies the same amount of space on an SMS network.
The practical rule is simple: write for the reader, but validate for the transport layer. When teams test the final composed message, account for dynamic fields, and measure actual segments, they can make informed choices about tone, reach, and cost without reducing every mobile message to plain and impersonal text.
 

source