SMS Encoding & Message Length

An SMS is not a free-form text field with a simple character cap. The number of characters that fit in a single message — and how many billable messages a longer text becomes — depends on which characters you use. This is a property of the SMS standard itself, not of Sent, and understanding it is the difference between a predictable one-part message and one that silently becomes three.

This page explains the mechanics. For how it maps to segment counts, billing, and practical tips on Sent — including a live calculator — see SMS Length, Segments & Cost.

Two encodings

Every SMS is encoded one of two ways, decided automatically by the characters in the message body.

GSM-7 (the default)

Standard SMS uses GSM-7, a 7-bit alphabet defined by the GSM 03.38 standard. It covers everything most Latin-script messages need:

  • Upper- and lower-case A–Z and the digits 0–9
  • Common punctuation and symbols
  • A set of accented and non-English Latin characters (à é ù ì ò Ç Ø Å Δ Φ Ñ Ä Ö Ü § and more)

A message that uses only GSM-7 characters fits 160 characters in a single SMS.

The GSM-7 extension table

A small set of characters are technically part of GSM-7 but live in an extension table. They're sent as an escape character followed by the character itself, so each one counts as two characters:

\    |    ^    €    {    }    [    ]    ~

(Plus one non-printable entry — the form-feed control character — for ten in total.)

A message like Balance: {amount} looks like 17 characters, but { and } are extension characters that each count as two — so it actually costs 19. It's still a GSM-7 message. A character that isn't in GSM-7 at all — an arrow (), an emoji, or a curly quote — is a different matter, and brings us to the second encoding.

Unicode (UCS-2)

The moment a message contains one single character outside the GSM-7 set, the entire message switches to Unicode (UCS-2), a 16-bit encoding. This includes:

  • Emoji and other non-GSM symbols (😀, ✅, →, ™)
  • Non-Latin scripts (Arabic, Chinese, Japanese, Korean, Cyrillic, Greek, Hebrew, Thai, …)
  • Many "smart" typographic characters that word processors and phones insert automatically — curly quotes (" "), en/em dashes (– —), and the ellipsis ()

A Unicode message fits only 70 characters in a single SMS.

One emoji re-encodes the whole message. Unicode applies to the entire body, not just the non-GSM character. Adding a single 😀 to a 100-character message doesn't add one character — it changes the encoding, dropping your limit from 160 to 70 and turning a one-part message into a two-part one. The most common accidental trigger is a curly quote or an em dash pasted in from another app.

Single message limits

EncodingTriggered bySingle-message limit
GSM-7Latin text within the GSM 03.38 set160 characters
UCS-2 (Unicode)any emoji, non-Latin script, or non-GSM symbol70 characters

Longer messages: concatenation

When a message exceeds the single-message limit, it isn't rejected — it's split into multiple segments that the recipient's phone stitches back together into one seamless message. This is called concatenation.

Concatenation isn't free of overhead. Each segment carries a small User Data Header (UDH) that tells the receiving phone how many parts there are and in what order to reassemble them. That header consumes space that would otherwise hold message content, so the per-segment limit is lower than the single-message limit:

EncodingSingle messagePer segment when concatenated
GSM-7160153
UCS-2 (Unicode)7067

So a 161-character GSM-7 message doesn't split into 160 + 1 — it splits into two segments of up to 153 characters each. A 300-character GSM-7 message is 2 segments; a 459-character one (3 × 153) is exactly 3, and a single character more tips it into a 4th.

A GSM-7 extension character can't be split across a segment boundary. Because characters like { or are a two-character escape sequence, if one would land on the boundary between segments it's pushed wholesale into the next segment. In rare cases this means a message sits one character below a limit yet still rolls to an extra segment.

Template body limit

When you create or update a template, Sent enforces a 1,024-character limit on the stored template body. This applies to the raw body as it sits in the database — with all {{variable_name}} placeholders still present and unsubstituted.

What is measuredWhat is NOT measured
The stored template body, including {{...}} placeholder textThe rendered message after variables are substituted
Every character counted equally (encoding-blind)GSM-7 vs Unicode distinction — the limit is the same for both

The limit is encoding-blind. Sent counts each UTF-16 code unit as one character — the same behavior as .NET's string.Length or JavaScript's String.prototype.length. Most Latin, accented, Cyrillic, and other characters within the Basic Multilingual Plane each count as 1; most common emoji (faces, flags, hearts) are outside the BMP and count as 2. A template body longer than 1,024 characters will be rejected at save time regardless of encoding.

There is no post-substitution validation. A template body well within 1,024 characters can produce a rendered message that is significantly longer once variables are expanded. For example, a placeholder like {{long_url}} is 12 characters in storage but could expand to 80+ characters at send time. Plan variable lengths accordingly and use the SMS Length, Segments & Cost guide to estimate rendered segment counts.

You can include as many dynamic variables as you need — there is no limit on the number of {{...}} placeholders, only on the total character count of the stored body.

Why it matters

Three consequences follow directly from the above, and each is covered in the companion guide:

  • Cost. Each segment is a separately billed SMS. A message you think of as "one text" can bill as three.
  • Predictability. A template that's comfortably within 160 characters in English can exceed 70 once translated into a non-Latin script, or once a variable expands.
  • Deliverability. More segments mean more parts that must arrive and reassemble correctly; not every network handles long concatenated messages identically.

On this page