Understand SMS encoding and message length

Predict how many SMS parts your content uses before sending it with API v1.1.

How cloudnumbering counts content

cloudnumbering selects one encoding for the complete message:

• Content containing only the GSM-7 basic and extension sets uses GSM-7.
• If any character is outside those sets, the complete message uses Unicode and is counted in UTF-16 units.

The limits are:

When content exceeds the one-part limit, cloudnumbering uses the multipart capacity to calculate every part. For example, 161 GSM-7 basic characters use two parts, not one full part plus one character.

Count GSM-7 extension characters

These supported GSM-7 extension characters each use two septets:

^ { } \ [ ] ~ | €

Other GSM-7 characters use one septet. A message made entirely of extension characters can contain 80 characters in one part or 459 characters across the six-part maximum.

Count Unicode content

Unicode content is counted in UTF-16 units, not visible characters or Unicode code points. Many characters use one unit, but some characters, including many emoji, use two.

For example:

Apply the six-part limit

cloudnumbering accepts at most six parts in one outbound API message. Content over 918 GSM-7 septets or 402 UTF-16 units needs more than six parts and is rejected with 400 and message too long.

Each part is charged separately. To reduce the number of parts:

• Remove unnecessary content.
• Replace Unicode punctuation or emoji with GSM-7 alternatives when suitable.
• Remember that each GSM-7 extension character counts twice.
• Calculate length after inserting any dynamic values.

Verify the final request

The API does not provide a separate message-length preview. Count the completed content value in your application before calling POST /v1.1/sms, then handle message too long as a validation failure.

See Send SMS with API v1.1 for the runnable request and retry warning.

Next steps

• Send an SMS API reference
• SMS encoding and message length
• MMS support