Skip to main content
Smart encoding automatically replaces Unicode characters with visually similar GSM-7 characters. This keeps your messages in the more efficient GSM-7 encoding, reducing segment counts and costs.
Smart encoding applies to SMS only. MMS and RCS messages use UTF-8 encoding by default and are not affected.

Why use smart encoding

SMS messages using GSM-7 encoding fit 160 characters per segment. When a message contains even one Unicode character outside GSM-7, the entire message switches to UTF-16 encoding, which only fits 70 characters per segment. A single smart quote (") or em dash () can more than double your messaging costs. Example: Smart encoding is especially valuable when your message text originates from word processors, CMS platforms, or mobile keyboards that silently insert Unicode characters like curly quotes, em dashes, or non-breaking spaces.

How it works

When smart encoding is enabled:
  1. Your message text is scanned for Unicode characters that have GSM-7 equivalents.
  2. Matching characters are automatically replaced (e.g., "", -, ...).
  3. The final encoding (GSM-7 or UTF-16) is determined after all substitutions.
  4. The segment count is recalculated based on the transformed text.
  5. The API response includes metadata about the transformation.
Webhooks return the original text. The text field in delivery webhooks contains your original message, not the smart-encoded version. This ensures your application’s message tracking stays consistent.

Enable smart encoding

You can enable smart encoding at two levels: on a messaging profile (applies to all messages) or on a per-request basis.

On a messaging profile

Enable smart encoding as a default for all messages sent through a profile.

Per-request control

Override the profile setting on individual messages using the encoding parameter:
The request-level encoding parameter takes precedence over the messaging profile’s smart_encoding setting.

Response metadata

When smart encoding is applied, the API response includes detailed metadata:
The parts field in the top-level response reflects the segment count after smart encoding, so you always see the actual billing impact.

Checking the response

Precedence rules

Smart encoding behavior is determined by a combination of your messaging profile setting and the per-request encoding parameter:
The request-level encoding parameter always takes precedence over the messaging profile setting.

Character substitutions

Smart encoding replaces 200+ Unicode characters with GSM-7 equivalents. The tables below show all supported substitutions grouped by category.
Fullwidth uppercase (U+FF21–U+FF3A) → A–ZFullwidth lowercase (U+FF41–U+FF5A) → a–zSmall capital letters:
Greek capital letters that visually resemble Latin letters are substituted:
These characters are replaced with a standard space or removed:
These control characters are removed or transformed:
Tab characters (U+0009) are converted to 7 spaces, which can significantly increase message length and affect segment count.

Edge cases

Some substitutions increase message length. For example:
  • Horizontal ellipsis () becomes three periods (...) — adds 2 characters
  • Tab (U+0009) becomes 7 spaces — adds 6 characters
  • Vulgar fractions like ½ become 1/2 — adds 2 characters
The segment count is calculated after these replacements, so a message near the 160-character limit may become multi-part after transformation.
If your message contains both replaceable Unicode characters and non-replaceable ones (like emojis), smart encoding still applies all possible substitutions. However, the non-replaceable characters will keep the message in UTF-16 encoding.This is still beneficial — fewer Unicode characters means a shorter UTF-16 message and potentially fewer segments.
The characters ~, ^, |, \, {, }, [, ] are part of the GSM-7 extended set and count as 2 characters each when calculating segment length. Smart encoding accounts for this when determining the final segment count.
Zero-width characters (like U+200B zero-width space) are removed entirely. If your message consists entirely of zero-width or control characters that all get removed, the API returns a 400 error — messages cannot be empty after transformation.
If you set encoding=gsm7 on a request but the message contains characters that cannot be represented in GSM-7 (e.g., emoji), the API returns a 400 error rather than silently dropping characters.

Limitations

  • SMS only — MMS and RCS use UTF-8 encoding by default and are not affected by smart encoding.
  • Not all characters convert — Emojis and non-Latin scripts (e.g., Chinese, Arabic, Cyrillic) have no GSM-7 equivalents and will still trigger UTF-16 encoding.
  • Visual differences — Substitutions may slightly alter the appearance of your message. Review the character tables above to understand what changes will occur.
  • Length may increase — Some substitutions produce longer output (e.g., ...). Always check the response metadata for the actual segment count.

Message Encoding

Learn about GSM-7, UTF-16, and segment calculations.

Send Your First Message

Get started with the Telnyx Messaging API.

Messaging Profiles API

API reference for updating messaging profile settings.

Messages API

API reference for sending messages with encoding options.