Methodology & Accuracy

Every checker on CharLimit.net runs on one small, tested engine. This page states exactly what that engine computes, which platform behaviors it models versus merely describes, and where the honest uncertainty lives — because a limit checker that hides its own margins is not much of a checker.

The unit of counting: Unicode code points

Limit checks count Unicode code points — the convention most platforms document for their caps. Concretely: é is one character whether it arrives precomposed or as e-plus-accent renders it, a CJK character is one, and an emoji like 🎉 is one code point even though it occupies two UTF-16 units in JavaScript's internal representation. Multi-part emoji are the known wrinkle: a family emoji such as 👨‍👩‍👧 is a single visible glyph built from several code points joined by invisible joiners, and this counter reports the code points. Platforms themselves disagree on such sequences, which is one reason the final authority on a borderline draft is always the platform's own composer.

SMS: a genuinely different algorithm

The SMS counter does not count code points against a cap — it implements the GSM 03.38 arithmetic. The engine walks your message character by character against the GSM-7 alphabet table: basic-set characters cost one septet, the extended set (€ [ ] { } ~ ^ \ |) costs two, and the first character outside both sets switches the entire message to UCS-2, where length is counted in UTF-16 code units instead (most emoji cost two). Segment math follows from the encoding: GSM-7 fits 160 septets in a single message or 153 per segment once concatenation headers are needed; UCS-2 fits 70, or 67 concatenated. The counter shows the detected encoding explicitly so an invisible flip — a curly apostrophe pasted from a word processor is the classic cause — is never silent. National-language shift tables and carrier-side transcoding exist at the margins and are not modeled; carriers can and do vary.

Modeled versus described

Some platform rules run in the engine; others are stated on the page but deliberately not simulated. The distinction is drawn where simulation would require guessing at server-side behavior we cannot verify from the outside:

  • Modeled: code-point counts against each platform's published cap, and the full GSM-7/UCS-2 segmentation above.
  • Described, not modeled: X's weighted counting (every URL fixed at 23, emoji and CJK weighted 2 — per X's developer documentation as of mid-2026), Instagram's ~125-character feed fold, YouTube's device-dependent title truncation, and Google's pixel-width snippet cut. Each page explains the quirk and tells you which direction it skews the count you see here.

The secondary word counts shown on the stat cards use Unicode-aware word detection: runs of letters and digits, with internal hyphens and apostrophes keeping a word whole.

Where the numbers come from

SMS behavior follows the GSM 03.38 standard — a stable specification, which is why this site states its arithmetic without hedging. Platform caps, by contrast, are product decisions: the 280, 2,200, 100, and ~160 figures reflect each platform's published rules as of mid-2026 and are stated with their history where it matters (X's limit was 140 until 2017; paid tiers now post longer). When a platform changes a limit, the page copy and preset are updated — and until you have verified a consequential send against the platform itself, treat any third-party counter, including this one, as a drafting aid rather than a guarantee.

Tested against pinned cases

The engine is a set of pure, typed functions with an automated test suite that pins the cases that have historically broken counters of this kind: GSM-7 alphabet membership (including the characters most often gotten wrong — Ü and § are basic-set, curly quotes are not, form feed is extended), the one-segment/two-segment boundary at exactly 160 and 161 septets, extended characters priced at two septets, the encoding flip to UCS-2 on a single emoji with UTF-16-unit counting, astral emoji as one code point in limit checks, and Unicode word detection across scripts. A build cannot ship with a failing case. If you believe a count is wrong, the contact page explains exactly what to include; confirmed issues are fixed in the engine and locked in with a new test.

Privacy as a design constraint

Everything you type or paste is processed locally in your browser. Nothing is transmitted, logged, or stored — there is no server-side counting endpoint at all, which you can confirm in your browser's network tab while typing.