OTP Message Design: GSM-7, Unicode and Segments

Quick answer: the length you see in a text editor is not enough to predict SMS segmentation. Encoding, extension characters, Unicode representation and multipart headers affect the result. For an app you own, review the exact rendered template in the sending provider's tooling before a release. Keep the code and security context clear rather than removing essential information just to hit a target length.

Separate a message from its transport parts

One logical OTP message may travel as several SMS segments. A device may combine them for display, but that visual result does not mean only one transport part existed. Segment count and message count therefore answer different operational questions.

Suppose a translation adds a non-GSM character to an otherwise short English template. The content may still look almost unchanged while its encoding and capacity change. Treat template changes as functional changes, not only editorial changes.

This guide concerns composing messages in your own sending application. It does not describe PhoneBorn as an SMS broadcast provider, define its billing, or claim that it exposes encoding diagnostics to customers.

Use the common limits as a starting point

Twilio's character-limit documentation and AWS's SMS character guidance explain these common capacities. They are not universal character-count promises for every route, header or implementation. Read your provider's current restrictions and limits.

A character from the GSM extension table can consume more than one septet. Some Unicode symbols occupy more than one code unit. Consequently, counting visible symbols or JavaScript string characters without understanding the encoding can produce a misleading estimate.

Review punctuation and localization deliberately

A content editor may replace straight punctuation with typographic punctuation, insert an emoji or paste an invisible character. Depending on the exact symbol and provider handling, that can change the selected encoding. Do not assume that every accent causes the same result: the GSM alphabet already includes some accented characters.

Localization should prioritize meaning. Do not remove letters from a person's language simply to preserve an English template's segment count. Instead, assess the localized rendered message, decide on an appropriate length and test how it appears on the intended receiving surface.

Keep a controlled template version for each locale. If the application inserts a brand, action label or dynamic value, test realistic maximum lengths rather than measuring only an empty template.

Put the action and secret in an understandable context

A useful template identifies the service and the action the person initiated, then presents the code clearly. Avoid mixing a login secret with marketing copy, promotions or an instruction to call an unfamiliar number.

An illustrative template can be expressed without a real code: “Example Service sign-in code: [CODE]. Use only for the sign-in you requested.” The placeholder is intentional. Do not publish a currently usable OTP, and do not assume this exact wording satisfies every sender-registration or origin-bound autofill requirement.

If adding a domain-bound line for a supported browser flow, review its exact syntax separately. A well-intentioned editorial cleanup can break machine-readable structure even while preserving readability.

Test boundaries instead of trusting one short sample

Use a pre-send worksheet before any billable test:

Provider calculators and local fixtures can answer many questions without sending a real message. If live testing is later necessary, use an approved budget and accounts you own. These are recommended tests, not results from a PhoneBorn delivery benchmark.

Trace segmentation without exposing OTPs

Record a template identifier, locale, encoding selection and estimated or reported part count when your sending stack supports those fields. Keep the live code out of ordinary logs and analytics. A stable placeholder lets reviewers reproduce the layout without receiving an authentication secret.

If actual delivery differs from your estimate, compare the final rendered payload with the template version that was measured. An appended footer, link rewriting or provider normalization may make the sent text different from the draft. Check the documented behavior rather than assuming the receiver edited the content.

For a message that does not appear, our SMS troubleshooting guide addresses the recipient side. Encoding review is one diagnostic layer, not an explanation for every delivery failure.

Keep commercial and security claims out of the calculation

Do not convert a segment estimate into a customer price unless you have the actual provider, destination, contract and applicable billing rules. Nor should a one-segment template be described as guaranteed faster or accepted by every carrier.

Keep authentication validity independent of segment receipt. A code that arrives in a complete message can still be expired or associated with a different request. Your application must validate the challenge, not infer success from the transport format.

For PhoneBorn users, the product facts distinguish access to a number from recipient-service acceptance. Neither an encoding choice nor a valid telephone format forces another app to issue a usable verification code.

Frequently asked questions

Is every visible character one GSM-7 unit?

No. Extension-table characters can require additional space, and Unicode counting has other complications.

Must I remove all non-English text?

No. Preserve understandable language and evaluate each rendered locale's encoding and length deliberately.

Does one segment guarantee delivery or a particular price?

No. Routing, policy, capabilities and the applicable commercial terms remain separate considerations.