LOGIC TELECOM
CommunicationsAugust 2, 20266 min read

SMS segmentation: GSM-7, Unicode and actual message length

How encoding affects SMS length and cost: GSM-7 and Unicode limits, concatenated messages, extended characters, template validation and segment monitoring.

An SMS text is converted into one or more segments before transmission
Contents

SMS length is determined by encoding and transmitted segments, not simply by the number of visible characters. Text that fits the GSM-7 alphabet can usually use 160 characters in one segment, while a message containing Cyrillic text normally uses Unicode and fits 70 characters. Once a message becomes concatenated, the practical capacity falls to 153 GSM-7 characters or 67 Unicode characters per segment. A single quotation mark, emoji or customer name can therefore change throughput, cost and queue time.

Why characters are counted differently

An SMS carries a tightly limited amount of data. The messaging platform selects a representation according to the characters in the final text:

  • GSM-7 provides a compact alphabet for Latin letters, digits and a defined set of symbols;
  • Unicode is normally required for Cyrillic and many other writing systems, special symbols and emoji;
  • binary mode supports specialised machine scenarios rather than ordinary text messaging.

A Russian-language template will almost always require Unicode. That is not a defect to work around with forced transliteration. The operational goal is to know the final segment count before submission and include it in capacity and budget calculations.

Some GSM-7 symbols sit in an extension table and consume two septets. Curly brackets, a backslash, the euro sign and several other characters may therefore use more room than their visual length suggests.

Single and concatenated messages

Typical useful limits are:

Encoding Single segment Concatenated SMS, per segment
GSM-7 160 characters 153 characters
Unicode 70 characters 67 characters

A concatenated message reserves part of each segment for a User Data Header. The header tells the handset which parts belong together and in which order to assemble them. The recipient normally sees one message, but the network and billing chain process multiple segments.

These values are practical baselines rather than a substitute for the platform’s own calculation. Encoding behaviour, long-message support and charging rules depend on the route, operator and commercial agreement.

How an extra segment appears unexpectedly

The editorial text is only part of the final payload. Variables change the message after rendering:

Order 74821 is ready. Collect before 18:00 at: {{pickup_address}}

A short address may keep the message in one segment. A long address, building name and entrance instructions can add a second or third. The same problem appears with:

  • customer names;
  • company and product names;
  • order identifiers of variable length;
  • dates and time-zone labels;
  • unshortened links;
  • smart quotes and long dashes;
  • a character from an unexpected writing system;
  • an emoji introduced by a CRM or content editor.

Testing only the static template is insufficient. Teams need minimum, representative and maximum permitted values for every variable.

Do not rely on a generic string-length function

An application language may count bytes, code units or user-perceived characters. None of those values guarantees agreement with the SMS encoding used on the route.

A reliable preview function should return:

  • the selected encoding;
  • the number of encoded units;
  • the segment count;
  • remaining capacity in the final segment;
  • characters that triggered a move from GSM-7 to Unicode;
  • the final rendered and normalised text.

When a communications platform provides this preview, call it before placing the message into the send queue. A local implementation needs fixtures for the GSM-7 basic and extension tables, Cyrillic, combining characters and emoji.

Normalisation must be controlled

Character replacement can sometimes reduce segment count. A smart quote may become a straight quote, a non-breaking space may become a normal space and a long dash may become a hyphen. Unconditional normalisation, however, is risky.

It must not:

  • alter names, addresses, codes or legally significant wording;
  • transliterate text without an approved policy;
  • remove symbols that change meaning;
  • shorten a critical instruction merely to save one segment;
  • run after a signature or checksum has been calculated.

Separate safe technical substitutions from editorial changes that require approval by the template owner.

How segmentation affects throughput

If a platform sends 1,000 business notifications and the mean message size is 2.4 segments, the gateway processes approximately 2,400 segments. That value affects the queue and available TPS.

This is why SMS throughput and queue capacity must be planned in segments rather than business events. Moving the average from 1.1 to 1.8 segments produces a comparable increase in gateway load even when the notification count does not change.

Useful measurements for each traffic class include:

  • mean and P95 segments per message;
  • the distribution of one-, two- and multi-segment messages;
  • Unicode share by template;
  • cost per business event;
  • delivery time by segment count;
  • templates with an abrupt distribution shift.

These measurements complement DLR and delivery-latency metrics. A final delivery status alone cannot explain why a queue suddenly drains more slowly.

Where to enforce the check

The control belongs in several layers.

Template editor

Show encoding and segment count while the author types. Give each variable representative and maximum values. A warning should explain the triggering character or length rather than saying only that the message is too long.

Submission path

Recalculate after rendering real data. Apply a limit by message class: OTP may use a strict one-segment policy while a service notification can allow more room.

Analytics

Store template version, final encoding and segment count beside the message identifier. This makes it possible to connect a copy change with cost, queue behaviour and delivery performance.

Handling long content

Not every long message should be truncated mechanically. Start with its purpose:

  1. An OTP message needs the code, expiry context and the minimum information required to recognise the action.
  2. A transactional notification must clearly describe the event and the next step.
  3. A detailed instruction can live on a trusted page while the SMS carries a concise summary and recognisable link.
  4. Marketing copy should be governed as a separate template class with its own limits.

Do not hide all critical context behind a link. The message itself should help the recipient identify the sender and understand why it was sent.

Template launch checklist

  • calculate segments after realistic variable substitution;
  • test minimum and maximum variable lengths;
  • cover Cyrillic, Latin, quotes, dashes and emoji;
  • document permitted normalisation;
  • verify concatenation on several handsets;
  • confirm route charging and technical limits;
  • collect encoding and segment metrics;
  • alert on distribution changes;
  • load-test with the actual average segment count;
  • retain the exact template version for support investigations.

When selecting an SMS platform, confirm that it offers an encoding preview, transparent segment reporting and consistent results across API and SMPP connectivity. Message length then becomes a governed integration parameter instead of an unexpected line on the invoice.

SMSA2PSMPPNotifications

Read also