Create SMS templates with variables, preview rendered messages, and track character counts.
| Encoding | 1 SMS | 2 SMS | 3 SMS |
|---|---|---|---|
| GSM-7 (English, numbers) | 160 chars | 306 chars | 459 chars |
| Unicode / UCS-2 (emojis, Hindi, etc.) | 70 chars | 134 chars | 201 chars |
The SMS Template Builder helps you draft transactional and promotional SMS messages with reusable placeholder variables such as {name}, {otp}, or {order_id}, then preview exactly how the final text renders once those values are filled in. As you type, it tracks the character count and shows how your message splits into SMS segments (160 GSM-7 characters per single part, 153 per part when concatenated, or 70/67 for messages containing Unicode/emoji), so you know before sending whether a template will cost one segment or several.
It is built for developers, marketers, and support teams in India who send SMS through gateways governed by TRAI's DLT (Distributed Ledger Technology) framework. The tool surfaces DLT-relevant guidance — variable placeholders, header/sender-ID conventions, and template-approval formatting — so the copy you write is easier to register with your operator and less likely to be rejected.
SMS uses one of two encodings. Plain Latin text fits GSM-7, which packs up to 160 characters in a single message; add any character outside the GSM-7 set (most emoji, many accented letters, non-Latin scripts) and the whole message switches to UCS-2/Unicode, dropping the limit to 70 characters. When a message exceeds one segment, carriers reserve a few bytes per part for reassembly headers, so the effective limits fall to 153 characters per part for GSM-7 and 67 per part for Unicode. This tool applies those exact thresholds so the segment count you see matches what your gateway will bill.
Under India's DLT framework, every message body must map to a pre-approved 'content template' registered against a sender ID (header). Approved templates keep static wording fixed and allow variable fields — the {name} or {otp} placeholders you insert here — to change per send. Keeping placeholder syntax consistent and avoiding disallowed promotional phrasing in transactional templates makes registration smoother and reduces the chance an operator flags a mismatch between your sent content and your registered template.
Anything you wrap in curly braces, like {name} or {order_id}, is treated as a placeholder that stays in the template but can be replaced with real data at send time. This mirrors the variable fields DLT content templates use, and the tool detects each one so you can supply a sample value for the preview.
An emoji or any non-GSM-7 character forces the entire message into Unicode (UCS-2) encoding, which cuts the single-segment limit from 160 to 70 characters. That is why one emoji can suddenly double or triple your segment count and cost.
One segment holds 160 characters in standard GSM-7 encoding or 70 in Unicode. Longer messages are split into concatenated parts of 153 (GSM-7) or 67 (Unicode) characters each, because a small header is reserved in every part for reassembly.
No. It is a builder and previewer only. It helps you format a compliant template and estimate segments, but you still copy the result into your operator's DLT portal for approval and into your own SMS gateway or API to actually send.
Yes, it is completely free to use. The message text and sample values you enter are processed in your browser for previewing and counting; the content is not submitted to a server as part of building the template.
Yes. It is well suited to OTP, order-status, and other transactional messages where a fixed body carries one or two variables like {otp} or {amount}. Keeping such templates short also helps you stay within a single billable segment.
DLT-approved templates expect the static text to stay constant while only the variable fields change per recipient. Keeping placeholders means the same registered template serves every send, so you copy the template (with braces) into your API and inject values at runtime.