SMS Character Counter

What this checker counts

The SMS counter does not count characters against a cap. It implements the GSM 03.38 arithmetic: the engine walks your message character by character against the GSM-7 alphabet table. Basic-set characters cost one septet. The extended set — € [ ] { } ~ ^ \ | — costs two. The first character outside both sets switches the entire message to UCS-2, where length is counted in UTF-16 code units instead, and most emoji cost two. The budget then follows from the encoding: GSM-7 fits 160 septets in a single message, or 153 per segment once concatenation headers are needed; UCS-2 fits 70, or 67 concatenated.

The result panel reports three things, in this order: the segment count with the detected encoding in brackets, the units used, and how many units are left before the next segment opens. The Characters card beneath it is a different number on purpose. It counts Unicode code points, the way the other checkers on this site do, so a message containing extended characters or emoji shows more units than characters. The units figure is the one the segment arithmetic runs on; the Characters card is there so you can see the gap between the two.

Where the budgets come from

The 160/153 and 70/67 budgets, the alphabet table and the two-septet extended set all come from GSM 03.38 — a stable standard rather than a product decision, which is why this page states its arithmetic without hedging. The figures here are current as of mid-2026; should the standard or the engine's table ever change, the page copy and the checker are updated together. What the standard does not fix is what happens after the message leaves your gateway, which the described-not-modeled section below covers. Until you have verified a consequential send against your provider, treat any third-party counter, including this one, as a drafting aid rather than a guarantee.

Worked examples, computed at build time

Each example below is an original draft run through the same engine the live checker uses; no figure in this section is typed in by hand. Paste any of them into the box above and the panel will match.

What is described, not modeled

The methodology page draws a line between rules that run in the engine and rules that are only stated. For SMS, the modeled part is the full GSM-7/UCS-2 segmentation shown above. Described, not modeled: national-language shift tables and carrier-side transcoding exist at the margins and are not modeled; carriers can and do vary. In practice that means the count here is the standard's count for your exact characters, and a gateway between you and the handset may encode the message differently from the table on this page. This checker does not try to predict that — simulating it would require guessing at behavior we cannot verify from the outside — so it reports the standard, shows the encoding it detected, and leaves the final word on a large send to your SMS provider's own segment count.

Reading a borderline draft

Check the encoding label first. If it says UCS-2 and you expected GSM-7, one character flipped it: a curly apostrophe or quote, an em dash, an emoji, or an accented letter outside the basic set. Replacing that single character restores the 160 budget, and the examples above show the size of the swing — the apostrophe pair goes from 16 left to 106 left with no other change.

Then read the units against the per-segment figure, not against 160. Once a message is over the single-segment ceiling, every segment holds 153 (or 67 in UCS-2), so "left before the next segment" is measured against the concatenated budget. That is why the full-segment example reads 145 left at 161 units rather than one over: the second segment arrived with its own room. Trailing whitespace counts too — a space or line break after the final character is a septet like any other, which is how a message that reads as exactly full in one place is two segments in another.

Finally, verify at the provider, not the handset. You cannot verify segmentation by texting yourself, because phones reassemble concatenated messages invisibly — the split shows up only on the bill. The arithmetic on this page is the standard's; the figure you are billed is your provider's, and for a large send the two should be compared before it goes out.

Common misreadings

• Reading the Characters card as the budget. It counts code points. The budget is spent in septets or UTF-16 units, and the two diverge the moment an extended character or an emoji appears — 72 characters against 76 units in the sale example.
• Expecting accents to flip the encoding, or expecting emoji not to. The basic set carries a specific list of accented letters, so a draft like the Zürich example stays GSM-7; every emoji is outside the set, so a single one always flips the message.
• Treating 160 as fixed after concatenation. The second segment does not add 160 on top of the first. Both drop to 153, which is why 161 septets leaves 145 spare rather than one over.
• The curly-apostrophe flip. The house example: a curly apostrophe pasted from a word processor is the classic cause of a silent switch to the 70 budget. The checker shows the detected encoding precisely so this is never silent — compare the apostrophe pair above.
• Assuming one extra character costs one more segment at the old rate. It costs a segment at the concatenated rate, and the parcel example shows the sharper version: one emoji moved a one-segment message to 2 by changing the budget it was measured against, not just by adding two units.

Frequently asked questions

Segmentation follows the GSM 03.38 standard (160/153 septets for GSM-7 with extended characters costing two; 70/67 UTF-16 units for Unicode). Carrier behavior can vary at the margins. Nothing you type is transmitted or stored. See the methodology page.