You write a promo in Google Docs. It looks clean, it's 148 characters, it fits comfortably under the 160-character single-segment line. You paste it into your sending tool and blast it to 10,000 contacts. Then the bill comes back at three times what you expected, and you have no idea why.

Here's what happened: somewhere in that text is a curly apostrophe. Or an em-dash. Or a "smart" quote your word processor helpfully inserted when you weren't looking. That single character flipped the entire message from GSM-7 encoding to Unicode (UCS-2), and the moment it did, your per-segment character limit collapsed from 160 to 70. Your "one segment" message became three.

Full disclosure: I work for Ready, an SMS platform. We bill per segment and itemize the carrier pass-through separately, so this exact problem shows up on our customers' invoices in a way it doesn't on tools that hide the math behind a rounded flat rate. That's why I care about it enough to write 1,400 words on apostrophes.

Two encodings, two very different budgets

Every SMS gets encoded before it travels the carrier network. There are two encodings that matter:

  • GSM-7 — the standard 7-bit alphabet. Covers A–Z, a–z, 0–9, basic punctuation, and a handful of common symbols. A single GSM-7 segment holds 160 characters. Multipart messages split at 153 characters each (the extra 7 bytes per part carry the "this is part 2 of 3" header).
  • UCS-2 (Unicode) — the 16-bit encoding used when your message contains any character not in the GSM-7 alphabet. A single Unicode segment holds only 70 characters. Multipart splits at 67.

The jump from 160 to 70 is not a rounding error. It's more than half your capacity, gone, the instant one non-GSM character sneaks in. And the characters that trigger it are almost always invisible to the person writing the copy — because they look nearly identical to the characters they replaced.

The characters that silently flip you to Unicode

The usual suspects are the "smart" typographic characters that Word, Google Docs, Apple Notes, and most modern editors substitute automatically:

What you typedWhat the doc turned it intoGSM-7 safe?
' straight apostrophe' curly apostrophe❌ Unicode
" straight quotes" " curly quotes❌ Unicode
- hyphen em-dash / en-dash❌ Unicode
... three periods ellipsis character❌ Unicode
-> arrow❌ Unicode
Any emoji 😊(already Unicode)❌ Unicode
Accented letters (é, ñ, ü)❌ Unicode

That first row is the killer. Every time you write a contraction — you're, don't, we'll, here's — a smart-quote editor swaps your straight apostrophe for a curly one. A single contraction in a promo you drafted in Google Docs is enough to cut your segment limit to 70 characters for the entire message.

If you've read the emoji tax post, this is the same mechanism, minus the emoji you can actually see. The apostrophe version is worse precisely because nothing on screen tells you it happened.

The before/after, with real segment math

Let's take an actual promo and run the numbers at Ready's Standard rate: $0.02/segment + $0.0045 carrier pass-through = $0.0245 all-in per segment.

The message (147 characters):

Hey Sam — we're dropping the fall collection today. Members get first pick + 20% off through Sunday. Here's your early link: rdy.co/fall

Count the characters and it's 147. Under 160. You'd expect one segment.

But look at what the editor did:

  • em-dash after "Sam"
  • we're curly apostrophe
  • Here's curly apostrophe

Three Unicode characters. The whole message is now UCS-2, capped at 67 chars per multipart segment. 147 ÷ 67 = 3 segments.

At 10,000 contacts:

ScenarioSegments eachTotal segmentsCost @ $0.0245
What you assumed (1 GSM segment)110,000$245.00
What actually sent (3 UCS-2)330,000$735.00

You paid $490 extra on a single send because of a dash and two apostrophes.

The fix takes 30 seconds

Retype the offending characters as their plain-ASCII equivalents:

Hey Sam - we're dropping the fall collection today. Members get first pick + 20% off through Sunday. Here's your early link: rdy.co/fall

  • - (plain hyphen)
  • both curly apostrophes → straight '

Now every character is in the GSM-7 alphabet. 147 characters ÷ 160 = 1 segment.

Same 10,000 contacts, now $245.00. Identical message to the reader — carriers render both apostrophe styles the same on the phone. You cut the bill by two-thirds without touching the wording.

This is the same lever pulled in the 2-segment-to-1 rewrite breakdown and the annotated abbreviation post, except here you're not even cutting words. You're just fixing punctuation your editor broke.

Where the downgrade actually happens

The trap is that the Unicode substitution happens upstream of your sending tool, in whatever app you drafted in:

  • Google Docs — smart quotes and em-dash autocorrect are on by default (Tools → Preferences).
  • Microsoft Word — "Straight quotes with smart quotes" under AutoCorrect → AutoFormat.
  • Apple Notes / Pages / iMessage — smart punctuation is a system-level iOS/macOS setting.
  • Slack, Notion, most chat apps — often auto-convert -- to an em-dash and ... to an ellipsis.

By the time you copy-paste into your SMS platform, the damage is baked in. The characters look fine. The only reliable tells are the segment counter jumping and the bill.

Two practical habits:

  1. Draft SMS copy in a plain-text editor. Notepad (Windows), TextEdit in plain-text mode (Mac), or any code editor. No smart substitutions, no surprises.
  2. Turn off smart quotes/dashes in whatever tool your team actually writes in, so the fix isn't one person remembering to retype.

And when you paste into a sending tool, watch the segment counter. If a 147-character message reports as 3 segments, you have a Unicode character hiding somewhere — hunt down the apostrophe.

When Unicode is actually worth paying for

I won't pretend GSM-7 is always the answer. Sometimes the Unicode character earns its cost:

  • Accented names and non-English copy. If you're texting a Spanish-speaking list, stripping every ñ and é to look "ASCII-clean" reads as careless. Pay for UCS-2 and write it correctly.
  • A single, deliberate emoji that lifts response on a specific campaign — test it, measure it, and if the reply rate justifies the 70-char ceiling, keep it.

The point isn't "never use Unicode." It's never use it by accident. If a curly apostrophe is costing you 2 extra segments across every send, that's pure waste. If a ñ in someone's name is the cost of respecting your list, that's a decision worth making on purpose.

The math scales with volume — and so does the transparency

The reason this matters more on some platforms than others: if your provider bakes the carrier fee into a rounded flat per-message rate, an accidental Unicode downgrade just quietly inflates a number you were never going to audit. On Ready, you see it — the $0.02 per segment and the $0.0045 carrier pass-through are line items, so a send that jumps from 10,000 to 30,000 segments is visible on the invoice. (We wrote about that pass-through transparency separately.)

At 10,000 contacts, an accidental downgrade cost the example above $490. Run that promo weekly and it's roughly $25,000 a year on punctuation nobody chose. Once you cross 50,000 segments in a month, Ready's Growth rate ($0.016/segment) applies automatically — but the smartest optimization is the free one: don't triple your segment count in the first place.

The takeaway

  • Any non-GSM-7 character flips your whole message from a 160-char limit to a 70-char one.
  • Curly apostrophes, em-dashes, and ellipses — all inserted automatically by Word and Google Docs — are the most common invisible triggers.
  • Retyping them as plain ASCII produces an identical-looking text at a third of the segment cost.
  • Draft in plain text, kill smart-quote autocorrect, and watch the segment counter before every blast.

If you want to check your own templates, paste them into the composer on a Ready account — the 2,500 free credits are enough to test a batch — and see whether your "one-segment" message is quietly running as three. You can sign up here without a card. Fix the apostrophes first; it's the cheapest optimization in SMS.