Unicode SMS: Why One Character Can Triple Your Cost and When You Need It Anyway

A marketer writes a perfect 155-character promotional text, well within the single-message limit, and sends it to 100,000 people expecting to pay for 100,000 messages. The invoice shows 300,000. The culprit: a single emoji at the end, or a curly apostrophe their word processor inserted automatically. That one character switched the entire message from standard encoding to Unicode, and Unicode holds less than half as much text per message.

This is the most expensive thing most people don't know about SMS. Encoding  how the characters in your message are represented in bits  quietly determines how many message segments you're billed for, and a single character outside a specific set flips the whole message to the expensive encoding. Understanding Unicode SMS isn't academic; it's the difference between a predictable messaging budget and a surprise on the bill.

This guide explains the two encodings and why they matter, exactly which characters trigger the costly one (including the invisible culprits), the segment math so you can calculate real costs, how to control it, and  because sometimes Unicode is non-negotiable  when you should simply embrace it and budget accordingly.

The two ways an SMS is encodedCopied

Every SMS is encoded in one of two ways, and the choice sets how much text fits in a single message segment.

GSM-7 is the standard 7-bit encoding used for ordinary Latin-script text. It fits 160 characters in a single segment. This is what you get, and what you want, whenever your message uses only the characters in the GSM-7 alphabet.

UCS-2 (Unicode) is a 16-bit encoding used whenever a message contains any character outside the GSM-7 set. Because each character takes more than twice the space, a Unicode segment holds only 70 characters.

That's the whole mechanism, and the entire cost story flows from it: the same physical SMS segment carries 160 GSM-7 characters or 70 Unicode ones. Which encoding your message uses isn't something you choose directly  it's determined automatically by the characters in your text. Include one character GSM-7 can't represent, and the message is encoded in Unicode in its entirety.

The cost cliff: how one character triples the billCopied

Here's why this matters so much. Encoding is all-or-nothing per message. You can't send 159 characters as GSM-7 and one emoji as Unicode; the presence of that single emoji forces the whole message into Unicode, and now your capacity per segment drops from 160 to 70.

Watch what that does to a message that was comfortably one segment:

A 155-character message fits in one GSM-7 segment. Add a single emoji and the same message, now Unicode, needs three segments  because at roughly 67 characters per concatenated Unicode segment, 155 characters spills across three. You've tripled the cost of every message in the send by adding one character. Across a large campaign, that's a genuinely expensive mistake, and it happens silently  nothing warns you, the message just costs three times more. This is the single most important thing to understand about bulk SMS marketing economics, and it's why careful senders check encoding before every send.

What actually triggers Unicode  including the invisible culpritsCopied

To control encoding, you have to know what forces it. Characters fall into three groups.

Safe (GSM-7 basic): the standard Latin letters A–Z and a–z, digits 0–9, spaces, common punctuation (. , ? ! : ; ' " ( ) / @ and straight quotes), and a set of specific accented and special characters that made it into the GSM-7 alphabet  including é, è, à, ù, ì, ò, ñ, ü, ä, ö, and the symbols £, ¥, §, ¿, ¡. Text using only these stays GSM-7.

Costs two characters (GSM-7 extension): a handful of characters are in GSM-7 but consume two character slots each  ^ { } \ [ ] ~ | and the euro sign €. They don't trigger Unicode, but they eat into your 160 faster than expected.

Triggers Unicode (everything else): any character not in the GSM-7 set forces the whole message to Unicode. This includes all non-Latin scripts  Arabic, Chinese, Japanese, Korean, Hindi and other Indic scripts, Cyrillic, Thai, Greek  all emoji, and, critically, some characters that look almost identical to safe ones.

That last category is where money leaks. The most common accidental Unicode triggers are:

Smart/curly quotes and apostrophes. A straight apostrophe (') is GSM-7; the curly version (') is not. Word processors and many content tools automatically "improve" straight quotes into curly ones, so text that looks fine silently becomes Unicode. The same applies to curly double quotes (" ") versus straight ones (").

Em dashes and en dashes. The long dashes (, –) that autocorrect inserts aren't in GSM-7; a plain hyphen (-) is.

Emoji. Every emoji forces Unicode. One 😊 turns your whole message expensive.

Certain accented letters. As covered in multilingual sending, some accents are in GSM-7 (é, ñ) and some aren't  the acute-accented á, í, ó, ú, for instance, are not, so a single accented word in Spanish or another language can flip the encoding.

The lesson: the danger isn't just obvious foreign scripts  it's the invisible substitutions your own tools make. A message pasted from a document can be Unicode without a single character looking out of place.

The concatenation mathCopied

Messages longer than a single segment get split and reassembled on the recipient's phone  concatenation. This uses a few bytes of each segment for a header that tells the phone how to stitch the parts together, which slightly reduces the usable characters per segment.

So the real per-segment capacities are:

This is why the emoji example produces three segments, not two: 155 Unicode characters at 67 per concatenated part needs three parts (67 × 2 = 134, short of 155). Knowing these numbers lets you calculate the true cost of any message: determine the encoding from the characters, then divide the length by the right per-segment figure, rounding up. Tools that count SMS segments do exactly this, and checking your exact copy in one before a send is the simplest way to avoid a billing surprise  a habit worth building into every bulk send at scale, where the multiplier hits hardest.

When you genuinely need UnicodeCopied

None of this means Unicode is bad  it means it should be deliberate. For a huge share of the world, Unicode isn't a cost trap to avoid, it's a requirement, because their language can't be written any other way.

If you're messaging in Arabic, Chinese, Hindi, Thai, Russian, Greek, or any non-Latin script, Unicode is mandatory  there's no GSM-7 alternative, and trying to avoid it would mean not communicating at all. The same is true for genuinely multilingual audiences and for brands whose voice legitimately needs an emoji or a special character. In these cases the right move isn't to fight Unicode but to plan for it: write concise messages knowing your budget is 70 characters per segment, and price your campaigns accordingly. A well-planned Unicode campaign in a customer's own language will always outperform a compromised GSM-7 one that mangles their script. Reaching multilingual audiences well sometimes also means translating messages properly rather than transliterating them into an awkward Latin approximation.

The distinction to hold onto: Unicode by accident is a costly mistake; Unicode by choice, for an audience that needs it, is simply the cost of doing business in their language.

Controlling Unicode costsCopied

Between accidental Unicode and mandatory Unicode sits a large middle ground where you can control costs deliberately.

Detect before you send. Run your exact copy through an SMS character counter that shows the encoding and segment count. This catches accidental Unicode before it reaches 100,000 recipients, and it's the single most valuable habit. A capable SMS API also reports the encoding and segment count back programmatically, so you can flag a Unicode message before the send rather than after.

Strip the invisible triggers. For Latin-script messages, replace curly quotes with straight ones, em dashes with hyphens, and remove stray special characters  often achievable without changing the meaning at all. Many tools can sanitise text to GSM-7 automatically. This alone recovers most accidental Unicode.

Decide on emoji deliberately. An emoji can lift engagement, but it triples cost. That's sometimes a worthwhile trade and sometimes not  the point is to make it a conscious decision, not an accident.

Weigh transliteration for non-Latin scripts  carefully. It's technically possible to write some languages in Latin characters (romanisation) to fit GSM-7 and cut costs. Sometimes this is acceptable to an audience; often it reads as awkward, unprofessional, or hard to understand, and damages the message more than the saved cost is worth. Transliteration is a genuine option for cost control, but only where the audience genuinely accepts it  never impose a mangled Latin approximation on people who read their own script fluently.

Budget for legitimate Unicode. Where Unicode is required, build the 70-character segment size into your cost model from the start, so it's a planned expense rather than a surprise.

Display and deliverability notesCopied

A couple of practical points round this out. Modern handsets universally support Unicode SMS, so display isn't a concern  your Arabic or Chinese or emoji-bearing message will render correctly on essentially any current phone. And Unicode content is fully compatible with standard A2P messaging infrastructure, with no penalty to delivery rates when sent on quality routes. In markets with template registration regimes, note that regional-language content is registered and sent as Unicode, so if you operate somewhere with DLT registration or similar, your local-language templates will use Unicode encoding by design  plan the character budget accordingly. For content that's straining against SMS limits because it wants images or rich formatting, that's often a sign the message belongs on a richer channel like RCS messaging rather than being forced into expensive multi-part Unicode SMS.

Unicode SMS checklistCopied

• Know your encoding before sending  check exact copy in a segment counter.

• Watch for accidental Unicode: curly quotes, em/en dashes, emoji, and non-GSM accents.

• For Latin-script messages, sanitise smart punctuation back to GSM-7 to stay at 160 characters.

• Treat emoji as a deliberate cost decision, not a default.

• Calculate real cost using the right per-segment figure (153 GSM-7 / 67 Unicode when concatenated).

• Where Unicode is required by the language, embrace it and budget for 70-character segments.

• Use transliteration only where the audience genuinely accepts it, never as a forced compromise.

The bottom lineCopied

Unicode SMS is a simple mechanism with expensive consequences: any character outside the GSM-7 set switches the whole message to an encoding that holds less than half the text, so one stray emoji or auto-inserted curly quote can triple the cost of an entire campaign without a single warning. The fix is awareness  know what triggers Unicode, check your encoding before you send, and strip the accidental culprits from Latin-script messages. And where Unicode is genuinely needed, for the billions of people whose languages require it, stop treating it as a problem and simply plan for its shorter segments. Manage encoding deliberately, and it stops being a hidden tax and becomes just another number you control.

SMSala handles both GSM-7 and Unicode messaging with encoding detection and accurate segment reporting, so you see the real cost before you send  but wherever you send from, the savings and the surprises both come down to understanding the character that flips the switch.

Frequently asked questionsCopied