SMS is a simple and familiar communication channel. Most of us remember old mobile phones that
showed a character counter while typing a message. Today, smartphones often hide this counter,
but the technical limits of SMS have not disappeared.
For anyone who works with SMS traffic, it is important to understand how message length is
calculated, why SMS can be divided into several parts, how this affects billing, and why long
messages may create real delivery risks.
The number of characters in one SMS depends on the encoding used in the message.
If the message contains only characters from the GSM 7-bit alphabet, one SMS can contain up to 160 characters.
If the message is longer than 160 characters, it is split into several parts. Each part reserves a small
amount of space for a technical header (User Data Header, or UDH) that helps the receiving device
understand that these parts belong to one message and should be assembled together.
Depending on how the sending platform is configured, each part can contain 152 or 153 characters:
| SMS type | Characters per part |
| Single SMS | 160 |
| Multi-part SMS (8-bit reference) | 153 |
| Multi-part SMS (16-bit reference) | 152 |
Both configurations are standard and valid. The 16-bit reference variant is more common on modern
high-throughput platforms because it avoids reference collisions between messages sent at the
same time. For simplicity, most industry documentation still says “153 characters per part” — but if
you see 152 in your provider’s calculator, that is not an error.
So a message of 161 characters will already be sent as two SMS parts.
If the message contains at least one character that is not included in the GSM 7-bit alphabet, the
whole message is sent using Unicode encoding (UCS-2).
Unicode allows using many more characters, including different alphabets, special symbols, and
emojis. However, it also reduces the available message length.
| SMS type | Characters per part |
| Single SMS | 70 |
| Multi-part SMS (8-bit reference) | 67 |
| Multi-part SMS (16-bit reference) | 66 |
This is one of the most important points to remember: even one Unicode character changes the
encoding of the entire SMS.
For example, if you add one emoji or one special symbol that is not supported by GSM 7-bit, the limit
will no longer be 160 characters. It will become 70 characters for one SMS or 66–67 characters per
part in a multi-part message.
When calculating SMS length, visible letters and numbers are not the only things that count. Spaces,
line breaks, tabs, and other invisible characters are also included in the total message length.
This is especially important for bulk SMS campaigns. A few extra spaces or line breaks may seem
insignificant, but at scale they can increase the number of SMS parts and, as a result, increase the
total cost of the campaign.
Before sending a campaign, it is always better to check the message length carefully.
Some symbols look simple but silently double the space they consume.
The GSM 7-bit alphabet has an “extension table” for a small group of characters that are not part of the base 7-bit set:
€ { } [ ] ~ \ | ^
Each of these characters takes the space of two GSM 7-bit characters, not one. So a message like
“Total: €100” (11 visible characters) is actually counted as 12 characters, not 11.
Note: the dollar sign ($) and the pound sign (£) are part of the standard GSM 7-bit alphabet and
count as a single character each — no penalty there. The euro sign (€) is the one to watch for.
For bulk pricing, marketing, or promotional messages that include the euro sign, always calculate
length with the extension penalty in mind.
Some invisible or nearly-invisible characters can force a whole message into Unicode encoding —
cutting the character limit from 160 to 70 in an instant.
The most common culprits, all easily introduced through copy-paste from Word, Google Docs, or design tools:
| Character | Looks like | Actually is |
| — | dash | em-dash (Unicode) |
| – | dash | en-dash (Unicode) |
| “ ” | quotes | smart / curly quotes (Unicode) |
| ‘ ’ | apostrophe | smart apostrophe (Unicode) |
| … | three dots | horizontal ellipsis (Unicode) |
| (nbsp) | space | non-breaking space (Unicode) |
Straight quotes (“), straight apostrophes (‘), regular hyphen (-), and three separate periods (…) all
stay within GSM 7-bit and do not trigger Unicode.
Practical advice for marketing teams: always prepare SMS text in a plain-text editor (Notepad, VS
Code, or any other simple editor without auto-correct), not in Word. If the text is coming from a
designer or copywriter, run it through a plain-text step before feeding it into the campaign tool.
One curly quote in your template can double the price of an entire bulk campaign.
Consider this order confirmation message:
Your order #12345 has been dispatched and will be delivered within 2-3 business days.
This is 86 characters. In GSM 7-bit it fits in one SMS (limit: 160). Cost: 1 SMS per recipient.
Now add a package icon at the start to make it look nicer:
📦 Your order #12345 has been dispatched and will be delivered within 2-3 business days.
This is 89 characters. But the emoji forces the whole message into Unicode, where the single-SMS
limit is 70. The message no longer fits in one part — it is split into two parts.
Cost: 2 SMS per recipient. At 100,000 recipients, that single emoji added 100,000 extra billed SMS to the campaign.
The same effect happens with a single smart quote, a euro sign in a message that is already close to
the length limit, or a single Cyrillic letter accidentally left in an otherwise Latin template. The visual
difference is invisible; the cost difference is not.
A long SMS may look like one message on the recipient’s phone, but technically it can consist of
several SMS parts. Each part is charged as a separate SMS.
| Message length | Billing |
| 1 part | Charged as 1 SMS |
| 2 parts | Charged as 2 SMS |
| 3 parts | Charged as 3 SMS |
| 4 parts | Charged as 4 SMS |
This is why message length directly affects campaign cost. If you send a long message to thousands
or millions of recipients, even one additional part can significantly increase expenses.
Always test the message before mailing.
The main risk of multi-part SMS is that each part is delivered separately. Although the recipient
usually sees one complete message, the message is actually divided into several parts on the
technical side. The receiving device is expected to reassemble these parts back into one text.
But the delivery of each part is independent — and this creates several practical problems.
Each SMS part is a separate SMPP transaction. Parts may take different routes through the network,
may be delayed by different amounts, and may arrive at the destination handset in a different order
than they were sent. The receiving handset uses the sequence number embedded in each part (part
1 of 3, part 2 of 3, part 3 of 3) to reassemble the message correctly — but only once every part has arrived.
This is the most important — and least known — fact about multi-part SMS on modern handsets.
Older phones sometimes displayed whatever parts arrived, even if some were missing. The user
would see a truncated or fragmented message. Modern iOS and Android devices do the opposite:
they wait for all parts before displaying anything to the user.
If your message has 3 parts and only 2 arrive, the user sees nothing at all. Not a partial message, not
a placeholder — nothing. The delivered parts sit in the phone’s memory waiting for the missing one,
and after a timeout they are silently dropped.
From a delivery-report perspective, 2 out of 3 parts were “delivered”. From the recipient’s
perspective, the message never existed.
The more parts a message has, the higher the risk that one of them may be lost somewhere in the
delivery chain — and the more likely it is that a partial success looks, to the user, like complete
failure.
This is why it is better to keep SMS messages short and avoid unnecessary segmentation.
For every SMS part sent through the network, the operator returns a separate Delivery Receipt
(DLR). This means a single “message” from the sender’s point of view can generate multiple DLRs —
one per part.
For a 3-part message, this can produce combinations like:
| DLR result | What the recipient actually sees |
| 3 × delivered | The complete message ✓ |
| 2 × delivered + 1 × undelivered | Nothing ✗ |
| 1 × delivered + 2 × undelivered | Nothing ✗ |
| 3 × undelivered | Nothing ✗ |
Notice that “2 delivered out of 3” is not “67% success”. At the user experience level, it is a complete
failure. Modern phones do not display partial multi-part messages — they wait for every part and
drop everything if any part is missing.
If your bulk-messaging reporting only counts individual DLRs, your dashboards may show a healthy
delivery rate while your actual users see nothing on their screens. This is a very real gap between
what your reporting says and what your customer support team hears about.
For CRM and campaign reporting, the correct metric for multi-part SMS is:
A message is considered delivered only if every part of it has been delivered.
Platforms that consolidate DLRs per full message — not per part — give a much more accurate
picture of what your recipients actually received.
The GATUM platform is designed to process long SMS messages and their parts correctly. The
platform can receive and process multi-part SMS messages and forward every received part to the
supplier.
However, no platform can fully guarantee how the final mobile operator will process and deliver
each part to the subscriber. GATUM can guarantee that all parts received by the platform will be
processed and forwarded according to the routing logic. Final delivery still depends on the operator
and the network.
To reduce the risks connected with incomplete multi-part delivery, GATUM includes a built-in SMS
assembly mechanism.
The logic is straightforward:
1. GATUM receives SMS parts as they arrive — potentially out of order, from different routes,
with different delays.
2. The platform tracks all parts that belong to the same message using their reference number
and sequence number.
3. The message is forwarded to the next hop only after every part has been collected.
4. If one or more parts are still missing, the platform holds the collected parts and waits.
5. The default assembly window is 10 minutes. If all parts arrive within this window, the
complete message is processed and sent further. If the window expires with parts still
missing, the incomplete message is logged and dropped rather than forwarded partially.
This 10-minute window is a deliberate balance:
This mechanism helps avoid situations where only part of a long message is sent to the supplier or
operator — which, as we saw above, is functionally the same as no delivery at all from the user’s
perspective.
The assembly window is a platform configuration and can be tuned per client or per traffic type
when there is a good reason to do so.
To avoid problems with SMS length and message parts, follow these basic rules:
SMS may seem simple from the user’s point of view, but technically it has many important
limitations. Message length, encoding, invisible characters, special symbols, and segmentation all
affect delivery quality and cost. A message that looks like one SMS on a phone may actually consist
of several separately charged and separately delivered parts — and if any of those parts is lost, the
message may never appear on the recipient’s screen at all.
Understanding these rules helps avoid unnecessary costs, reduce delivery risks, and improve the
quality of SMS communication.
GATUM helps process SMS parts correctly and reduces the risk of incomplete long messages
reaching the network — but the best approach is still to create clear, concise, and properly tested
SMS texts before sending.
