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, such as an arrow (→), an emoji, or a curly quote, is a different matter, and brings you 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.

Single message limits

Longer messages: concatenation

When a message exceeds the single-message limit, it isn't rejected. Instead, it's split into multiple segments that the recipient's phone stitches back together into one 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:

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 fourth.

Template body limit

Separately from these SMS-standard limits, Sent enforces a 1,024-character limit on stored template bodies at save time. This is a platform validation rule that applies regardless of encoding, documented with its counting semantics in the template definition reference.

Why it matters

Three consequences follow directly from these mechanics, 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.

Related