SMS character counter.
Paste a message. See exactly how many segments it'll cost, which encoding the carrier will use, and which characters force the message into double-byte UCS-2.
How it works
The 160 / 70 split (and why it costs you money).
SMS encoding is defined in 3GPP TS 23.038. The short version: every message is encoded as either GSM-7 (7-bit, 160 chars/segment) or UCS-2 (16-bit, 70 chars/segment). One non-GSM-7 character anywhere in the message bumps the whole thing to UCS-2 — your character budget gets cut by more than half, and so does the maximum length before the carrier starts billing per segment.
Characters that look harmless but force UCS-2
- Smart / curly quotes (“ ” ‘ ’) — auto-substituted by macOS, iOS, and most word processors. Use straight quotes (" ') instead.
- Em-dashes — and ellipses … — also auto-inserted by autocorrect. Use a hyphen-minus (-) and three dots (...).
- Accented letters not in the GSM-7 extension table — é ñ ü are fine; á í ó are not (without the extension). The counter above shows you exactly which one bit you.
- Any emoji — 😀 🎉 ✅ all force UCS-2.
- Arabic, Cyrillic, Chinese, Japanese, Korean — entire languages outside GSM-7. UCS-2 is the only option.
Multipart math
When a message exceeds the single-segment limit, the carrier wraps it in a User-Data Header (UDH) so the receiving handset can stitch the parts back together. That header eats 7 characters of payload per part — which is why multipart drops to 153 (GSM-7) or 67 (UCS-2) chars per segment instead of 160 / 70.
Most carriers (and BroadNet) bill per segment. The counter above shows the segment count in real time — trim a few characters below the next boundary and you can drop a segment.
Ready to send?
BroadNet ships a REST API, an SMPP bind, delivery-status webhooks and an official TypeScript SDK, with an OpenAPI 3.1 spec for every other language. Request test access and we reply within one business day.