Character is not one thing
Ask how many characters are in a string and there are four defensible answers. They agree perfectly on plain English and diverge the moment anything else appears.
| Unit | What it counts | Who uses it |
|---|---|---|
| Grapheme cluster | One thing a reader would point at | Human counts, well-built text editors |
| Code point | One Unicode scalar value | Python len(), Rust chars(), Go runes, most REST APIs |
| UTF-16 unit | One 16-bit slot | JavaScript .length, Java, C#, SQL Server nchar |
| UTF-8 byte | One byte of storage | File size, MySQL and Postgres byte limits, HTTP headers |
Take the family emoji made of four people. A reader sees one character. Unicode stores it as seven code points: four people joined by three zero-width joiners. JavaScript reports a length of eleven, because each of those four people is outside the basic plane and needs two UTF-16 units. UTF-8 encoding takes twenty-five bytes. One glyph, four honest answers: 1, 7, 11 and 25.
Which one your limit means is usually undocumented. This page shows all four at once so you can find out by experiment: type into the real field, count here, and see which of the four the field agrees with.
Why a text message splits
SMS predates Unicode and encodes text in a 7-bit alphabet called GSM 03.38, which holds the Latin alphabet, digits, common punctuation and a short list of accented and Greek characters. 160 of those fit in one message.
Anything outside that set — a curly quote from a word processor, an em dash, an emoji, Cyrillic, Chinese — forces the entire message into UCS-2, and the capacity drops from 160 characters to 70. Not the offending character: the whole message. One smart quote pasted in from elsewhere can turn a message that was going to send as one segment into three.
Longer messages are split and reassembled by the handset, which costs six bytes of header per part, so concatenated segments carry 153 GSM-7 characters or 67 UCS-2 characters each rather than the full 160 or 70. A 161-character message is therefore billed as two, not as one and a bit. The counter above reports the encoding, the unit count and the resulting segments, which is the figure that appears on an invoice.
The limits worth designing to
Some limits are enforced by software that rejects text over them. Others are display truncation, where you can write as much as you like and only the first part is ever seen. The second kind causes more trouble because nothing tells you it happened.
Search result titles are cut on pixel width rather than character count, so around 60 characters is a working figure but a title full of capitals and wide letters truncates sooner. Meta descriptions run to roughly 160 characters under the same caveat, and are frequently ignored in favour of text pulled from the page. Alt text has no technical ceiling, but screen readers read it as one uninterrupted run, and past about 125 characters the description stops helping and starts being an obstacle. Git commit subjects at 50 characters is a convention, not a rule, chosen so that git log --oneline stays on one terminal line.
Counting text nobody typed
Text arriving from a form, an export or another system tends to carry things that count. A trailing newline is the classic one: a textarea often adds one, most counters include it, and a field limit will reject on it while the visible text looks fine. Non-breaking spaces pasted from a word processor look identical to ordinary spaces and encode as two UTF-8 bytes rather than one. Zero-width characters and left-to-right marks survive copy and paste from a browser and are entirely invisible while still consuming the limit.
When a count is a few units off from what you expect and you cannot see why, the difference between the visible-character figure and the UTF-16 figure above is the first place to look, because invisible code points show up there before they show up anywhere else.
Questions people ask
Which of the four counts should I use?
Whichever one the system enforcing the limit uses, which is the awkward part, since almost nobody documents it. As rules of thumb: a limit in a JavaScript front end is nearly always UTF-16 units, because that is what .length returns; a REST API written in Python or Go is nearly always code points; a database column limit is usually bytes unless the schema explicitly says characters; and a limit described to a person in a design document usually means what a person would count. When it matters, test it — paste a single emoji into the real field and see how much of the limit it consumes. One means graphemes, two means UTF-16, four or more means bytes.
Why does one emoji sometimes count as more than one character?
Because most emoji you use are not one character. Emoji above the basic multilingual plane take two UTF-16 units each, which is why a plain smiling face is 2 in JavaScript. Beyond that, many emoji are sequences: a skin-toned hand is a hand plus a modifier, a flag is two regional indicator letters, a profession is a person plus a zero-width joiner plus an object, and a family is several people joined the same way. The renderer draws the sequence as one image, and every layer underneath still counts. Only a grapheme-aware counter, which is the first figure on this page, gives you the number a reader would.
Does a trailing newline count?
Yes, in every unit here, and it is a common source of an off-by-one. A newline is one code point, one UTF-16 unit and one UTF-8 byte, and this page counts it. Whether the field you are pasting into counts it depends on whether it trims the input first, and many do not. If your text is exactly at a limit and being rejected, delete the trailing blank line and try again before looking anywhere else. Windows-style CRLF line endings are worse, since they are two characters per line rather than one, which on a long list of lines adds up quickly.
How is this different from the text statistics tool?
Different question. This page answers "will it fit", so it counts the same text in every unit a limit could mean, checks it against common platform limits and works out SMS segmentation. Text Statistics answers "how does it read", so it reports the sentence length distribution, the longest sentence in full, Flesch Reading Ease and Flesch-Kincaid grade level, and the most repeated words. Use this one before you paste into a field with a cap, and that one while you are still editing the draft.