SMS segments and GSM-7, explained

An SMS is not 160 characters long. It is 160 septets long while every character comes from one small alphabet, 70 UTF-16 units long the moment any character does not, and shorter per part once it has to be split. This guide walks through that arithmetic — the GSM 03.38 rules the SMS character counter implements — on worked messages whose figures were computed at build time by the engine that runs the counter, and ends with what the counter deliberately does not model.

What a segment is

A single SMS carries a fixed amount of data. A message that fits is one segment; one that does not is split into several, each carrying a concatenation header so the parts can be reassembled in order. Those headers take room out of the same fixed envelope, which is why the allowance per part drops as soon as a message needs more than one: from 160 septets to 153 per segment in GSM-7, and from 70 UTF-16 units to 67 in UCS-2. Segments are what is actually sent, so for a large send the question is never "how many characters" but "how many segments" — and the second is not a simple function of the first.

Two encodings, two kinds of unit

GSM 03.38 defines the GSM-7 alphabet, and a message stays in it only while every character is in the table. The basic set costs one septet per character: unaccented Latin letters, digits, space, line break, common punctuation, and a specific selection of accented letters (é, ü, ñ, à and ö among them). The extended set — € [ ] { } ~ ^ \ | — costs two septets per character. The first character in neither set changes the encoding of the entire message to UCS-2, where length is counted in UTF-16 code units instead. Most emoji are one code point but two UTF-16 units, so in UCS-2 they cost two; the code-points guide explains why those two counts differ.

The flip does not penalize the offending character alone: it re-prices every character in the message, plain letters included, against the 70/67 budget. That is why a single emoji can turn a one-segment message into 3 — the last sentence of Example 4 does exactly that to the 160-septet message of Example 3 — and why the counter shows the detected encoding first.

The arithmetic, step by step

The engine runs this on every keystroke, in order:

1. Walk the message one character at a time: a basic-set character adds one septet, an extended-set character two.
2. The first character in neither set stops the walk. The message is UCS-2, and its length is its count of UTF-16 code units — the whole message, not just the part after the flip.
3. Pick the budget from the encoding: 160 single or 153 per concatenated segment for GSM-7; 70 or 67 for UCS-2.
4. Count segments: zero for an empty message, one within the single-segment allowance, otherwise the unit count divided by the concatenated allowance, rounded up.
5. Report the room left: the capacity of the segments in use (the single allowance for one segment, otherwise segments times the concatenated allowance) minus the units used — how many more units fit before another segment is needed.

Each example below shows those five outputs in that order.

Worked examples

Reading a borderline draft

Read the encoding first, the segment count second, the room remaining third. GSM-7 with units equal to characters means every character is basic-set; units above characters means the difference is the number of extended characters. UCS-2 means something is outside the table, and units exceed characters by one for every emoji that takes two UTF-16 units. The room remaining is the margin: zero means the message exactly fills its segments, and the next unit opens another.

The common misreadings all use the wrong unit. Treating 160 as a character limit misses the two-septet extended characters, so 68 characters can be 72 septets. Assuming any accent flips the encoding leads to needless rewriting, since é, ü, ñ and à are basic-set; assuming none does misses ô and its kind. Forgetting that a line break is a character undercounts: See you at 7. Bring the signed forms. is 37 characters and 37 septets. The quietest is the curly apostrophe of Example 6, which changes nothing you can see and everything the budget is measured against. When a flipped message surprises you, find the character responsible and replace it; the encoding readout tells you when you have succeeded.

What the counter does not model

The arithmetic above is the GSM 03.38 standard — a stable specification, which is why this site states it without hedging — and the counter stops where that arithmetic stops. National-language shift tables and carrier-side transcoding exist at the margins and are not modeled, and carriers can and do vary. The counter says nothing about delivery, display on the recipient's device, or what a particular provider will do with it: it reports the segment count the standard produces for the text you typed, and the encoding behind it. Until you have verified a consequential send against the platform itself, treat any third-party counter — including this one — as a drafting aid rather than a guarantee. The methodology page lists what is modeled and what is described across every checker.

Frequently asked questions

Every figure on this page was computed at build time by the engine behind the SMS character counter, following 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.