A single SMS carries at most 140 octets of user data. Encoded with the GSM 7-bit default alphabet that works out to 160 characters. Encoded with 16-bit Unicode it works out to 70. Text longer than that is not sent as one longer message. The sending system splits it into separate short messages called segments, each carrying a small header that tells the receiving handset how to put them back together. The recipient sees one message. The network, and the invoice, see several.
This is why a message that looks like one text can be charged as three, and why adding a single unusual character to a template can triple the cost of a campaign overnight.
Quick facts
| Maximum user data per SMS | 140 octets |
| Single message, GSM-7 encoding | 160 characters |
| Single message, UCS-2 encoding | 70 characters |
| Concatenated segment, GSM-7 encoding | 153 characters |
| Concatenated segment, UCS-2 encoding | 67 characters |
| Mechanism that links the parts | User Data Header, 6 octets in the common form |
| Who reassembles the parts | The receiving handset |
| Billing unit | The segment |
| Maximum segments, common form | 255 |
| Defining standards | 3GPP TS 23.038 (alphabets), 3GPP TS 23.040 (technical realisation) |
Where the 160-character limit actually comes from
The limit is not a design choice about how much people want to type. It is a consequence of packing.
The user data field of an SMS is capped at 140 octets. The GSM 7-bit default alphabet defined in 3GPP TS 23.038 uses seven bits per character rather than eight, and the specification packs those septets across octet boundaries with no wasted space. The arithmetic in clause 6.1.2.1.1 is explicit: in 140 octets it is possible to pack (140 × 8) ÷ 7 = 160 characters.
The same 140 octets carry only 70 characters when the message uses UCS-2, the 16-bit encoding used for scripts and symbols outside the GSM alphabet. Two octets per character, 140 octets, 70 characters.
So the number that matters is 140 octets. Everything else follows from how many bits each character costs.
GSM-7, Unicode, and the characters that cost double
Three encodings apply to SMS text, and the one your message ends up in is decided by its content, not by your preference.
| Encoding | Bits per character | Single message | Typical use |
|---|---|---|---|
| GSM 7-bit default alphabet | 7 | 160 characters | Latin text within the standard alphabet |
| 8-bit data | 8 | 140 octets | Binary payloads, not display text |
| UCS-2 | 16 | 70 characters | Cyrillic, Arabic, Chinese, Japanese, Korean, emoji, and Latin text containing characters outside the GSM alphabet |
The GSM alphabet is smaller than most people assume. It covers the Latin letters, digits, common punctuation, a set of accented characters used in western European languages, and a handful of Greek capitals. It does not contain curly quotation marks, en dashes, the ellipsis character, the degree sign, the bullet, or the non-breaking space. One of those characters anywhere in the message forces the entire message into UCS-2, dropping the limit from 160 to 70 in a single step. This is the most common and most expensive mistake in production messaging, and it usually enters through copy pasted from a word processor.
There is a second, quieter cost. TS 23.038 defines an extension table reached by an escape character, and every character in it consumes two septets rather than one. The extension table contains exactly these display characters:
^ { } [ ] ~ \ | €
A price notice ending in a euro sign is one character to a human and two septets to the network. A message of 159 ordinary characters plus a euro sign is 161 septets, which means two segments and two charges.
Why a concatenated segment holds 153 characters and not 160
Concatenation is described in 3GPP TS 23.040, clause 9.2.3.24.1. When a message is too long for one SMS, the sender splits it and marks each part with a User Data Header, a short block of metadata placed at the front of the user data field. The header carries three things: a reference number shared by every part of the message, the total number of parts, and the sequence number of this part.
In the common form, that header is six octets. The header is not sent alongside the 140 octets. It is sent inside them. Six octets of header leave 134 octets for text.
For UCS-2 the result is straightforward: (140 − 6) ÷ 2 = 67 characters per segment.
For GSM-7 it is slightly less obvious, because the text is packed in septets while the header is measured in octets. Six octets is 48 bits, which does not divide evenly by seven, so the packing rounds up to the next septet boundary at 49 bits. The header therefore consumes seven character positions out of the 160, leaving 153.
That is the whole explanation for a number that is quoted constantly and explained almost nowhere. If you have seen 154 published somewhere, it was arithmetic that forgot the rounding.
Working out the limit for any header
The concatenation header is not the only thing that can appear in a User Data Header, so 153 and 67 are not the only correct answers. Two formulas cover every case:
- GSM-7 characters = 160 − ⌈(header octets × 8) ÷ 7⌉
- UCS-2 characters = ⌊(140 − header octets) ÷ 2⌋
Applied to the headers you are most likely to meet:
| Header contents | Header size | GSM-7 characters | UCS-2 characters |
|---|---|---|---|
| None, single message | 0 octets | 160 | 70 |
| Concatenation, 8-bit reference number | 6 octets | 153 | 67 |
| Concatenation, 16-bit reference number | 7 octets | 152 | 66 |
| National language single shift | 4 octets | 155 | Not applicable |
| National language locking shift and single shift | 7 octets | 152 | Not applicable |
The last two rows are worth pausing on, because they are a good check on the formulas. TS 23.038 does not leave them to the reader. Annex C states directly that indicating a national language table at the start of a message takes four octets, corresponding to five 7-bit characters, which reduces the maximum length of a single message to 155 characters. It further states that combining locking shift and single shift takes seven octets in total, corresponding to eight characters, which reduces the maximum to 152. The formulas above reproduce both figures exactly.
Those national language tables exist so that Turkish, Portuguese, Spanish and several Indic scripts can be sent in seven bits instead of sixteen. In practice the benefit is inconsistent, because a handset that does not support the indicated table simply ignores the instruction and decodes the message with the default alphabet, showing different characters from the ones intended. The specification itself notes this and advises UCS-2 where several languages are mixed.
Where 152 and 66 come from
TS 23.040 defines a second concatenation format in clause 9.2.3.24.8 that uses a 16-bit reference number instead of an 8-bit one. Its header is seven octets rather than six, so its segments hold 152 GSM-7 characters or 66 UCS-2 characters.
The purpose of the wider reference number is to reduce the chance that two unrelated concatenated messages arriving at the same handset happen to share a reference and get interleaved into nonsense. It is a collision-avoidance measure, and it matters most for high-volume senders reaching the same handset repeatedly.
One frequent misreading is worth correcting. The 16-bit variant widens the reference number space, not the number of parts. In both formats the total-parts field is a single octet and a value of zero is invalid, which caps a concatenated message at 255 segments either way. At 153 characters per segment that is a theoretical ceiling of nearly 39,000 characters, which no carrier and no budget will ever let you approach.
So if you find 152 and 66 quoted where you expected 153 and 67, you have not found an error. You have found the 16-bit format.
The network does not join the parts, the handset does
This is the single most important structural fact about concatenation, and it explains most of the surprising behaviour senders encounter.
Each segment is a complete, independent short message. It is submitted separately, stored and forwarded separately by the SMSC, and delivered separately across the mobile network. Nothing in the network holds the set together or waits for the group to be complete. The reference number in the User Data Header is an instruction to the receiving device, and the receiving device is the only thing that acts on it.
This has three practical consequences.
Partial delivery is a real state. If two of three segments arrive and the third does not, the handset holds incomplete parts and cannot present the message. Depending on the device, the user may see nothing, a fragment, or the parts displayed out of order as separate texts. There is no network-level retry for the missing piece of a group.
Delivery receipts are per segment. A three-segment message produces three delivery receipts, each reporting on its own part. A dashboard that reports “delivered” at message level has made a decision about how to collapse those three results, and that decision is worth understanding before you rely on the number.
Throughput is measured in segments. When a route is described as supporting a certain number of messages per second, the relevant unit is almost always segments submitted, not messages composed. A campaign of three-segment messages consumes throughput three times as fast as a campaign of one-segment messages.
Segments are the billing unit
Almost every SMS provider prices per segment, because every segment is a separate short message crossing a separate carrier interconnect. That makes segment count, not character count, the number to forecast.
Some worked examples, all sent to the same destination:
| Message content | Encoding | Characters | Segments |
|---|---|---|---|
| 150 characters, plain Latin text | GSM-7 | 150 | 1 |
| 165 characters, plain Latin text | GSM-7 | 165 | 2 (153 + 12) |
| 320 characters, plain Latin text | GSM-7 | 320 | 3 (153 + 153 + 14) |
| 159 characters plus a euro sign | GSM-7 | 161 septets | 2 |
| 150 characters including one curly apostrophe | UCS-2 | 150 | 3 (67 + 67 + 16) |
| 300 characters of Arabic | UCS-2 | 300 | 5 |
Two things stand out. First, three segments do not give you 480 characters, they give you 459, because the header is charged to every part including the first. Second, the fifth row costs three times as much as the first for text of identical length. Nothing about the message looks different to the person who wrote it.
The practical discipline is to measure length after variable substitution, not before. A template that fits in one segment with the name “Ana” will not fit with the name “Aleksandra”, and a template that stays in GSM-7 with “Jose” will fall into UCS-2 with “José”. Budget for the longest substitution and the least convenient character set your recipient list contains.
Common mistakes
Counting characters in the editor rather than in the payload. Word processors and CMS fields silently convert straight quotes to curly quotes and hyphens to dashes. The character you typed is not always the character you sent.
Assuming emoji cost one character each. SMS Unicode encoding is 16 bits per unit. Most emoji sit outside the Basic Multilingual Plane and require two 16-bit units, so a 70-character allowance holds around 35 of them. Skin-tone modifiers and joined sequences such as family emoji consume considerably more than that, because each component and each joiner is counted.
Testing with English and shipping to a mixed list. A test send in plain ASCII proves nothing about a list containing Greek, Turkish or Vietnamese names.
Forgetting the text you did not write. Some destinations require an opt-out instruction, a sender prefix, or a regulatory suffix, and in some markets the terminating network appends or modifies content in transit. Text added downstream still counts towards the segment total.
Treating “delivered” as a message-level fact. It is a per-segment fact, aggregated by whatever logic your platform applies.
Assuming the recipient can tell. They cannot. A well-delivered concatenated message is indistinguishable from a single one, which is exactly why nobody notices the cost until the invoice arrives.
Where didlogic fits
didlogic operates at the voice and messaging infrastructure layer. It provides the routes and numbering that carry your traffic to mobile networks, not the application that composes your messages or the campaign tooling that schedules them. Encoding and segmentation are decided by your application before submission; what didlogic determines is which route the resulting segments take and what each one costs.
Two messaging products sit on that infrastructure. A2P SMS sends outbound application traffic under an alphanumeric sender ID without requiring a phone number, and two-way SMS numbers use an SMS-enabled DID so replies can return to the same number. Both are priced by destination and by segment count, and the documented character limits match the figures in this article: 160 GSM-7 characters for a single message or 153 per segment, and 70 Unicode characters for a single message or 67 per segment.
For anyone reconciling cost against content, the didlogic API returns the segment count alongside the delivery status, timestamps and cost for each message, so the encoding outcome of a given template can be checked against real sends rather than estimated. The Send SMS message and Get SMS message details endpoints are documented in the developer portal, and per-destination rates are published on the SMS rates page.
FAQ
How many characters is one SMS?
160 characters when the text uses the GSM 7-bit default alphabet, or 70 characters when it uses 16-bit Unicode. Both figures come from the same 140-octet user data limit.
Why is a concatenated segment 153 characters?
Because the six-octet User Data Header is carried inside the 140 octets. Six octets is 48 bits, which rounds up to 49 bits at the next septet boundary, consuming seven of the 160 character positions and leaving 153.
Why do some sources say 152 and 66?
Those are the figures for the concatenation format that uses a 16-bit reference number, defined in TS 23.040 clause 9.2.3.24.8. Its header is one octet larger.
Does the recipient see that the message was split?
Normally no. The handset reassembles the parts using the shared reference number and displays one message. Splitting only becomes visible when a part fails to arrive.
How many segments can a single message have?
The total-parts field is one octet and zero is not a valid value, so the ceiling is 255 segments. Carrier limits, filtering rules and cost will constrain you long before that.
Do emoji count as one character?
Not usually. SMS Unicode encoding counts 16-bit units, and most emoji require two of them. Sequences built from several components with joiners consume more still.
Does a link affect the segment count?
Only through its length and its characters. A long URL eats the character budget, and any non-GSM character in it, including some symbols in tracking parameters, will push the whole message into Unicode.
Is a concatenated message billed once or per segment?
Per segment. Each segment is a separate short message crossing the network, and providers price accordingly.
What happens if one segment is lost?
The handset holds incomplete parts and cannot present the full message. There is no network mechanism to retry only the missing piece.
Do these limits apply to MMS or RCS?
No. MMS and RCS are separate services with different transport and different size rules. The 140-octet limit and the concatenation mechanism described here belong to SMS.
Continue learning
