Counting words and characters: why the numbers disagree

The confusion starts with a single emoji. Take the family emoji 👩‍👩‍👧. To you it is one character. Stored as UTF-16, the encoding JavaScript and many other systems use internally, it is eleven code units. Stored as UTF-8 bytes, which is what a database column or an SMS gateway is usually measuring, it is more again.

Each of those is a legitimate count of something. What the reader perceives as one character is a grapheme cluster. What a program iterating over a string sees is code units. What a storage limit measures is bytes. They coincide exactly for plain English text, which is why the distinction stays invisible until someone types an emoji, an accented letter, or a word in Hindi or Thai.

The practical rule: when a limit is imposed by a person — a word count on an essay, a character limit in a style guide — they mean graphemes. When it is imposed by a system — a database field, an SMS segment, a URL — it almost certainly means bytes or code units, and it will be enforced without sympathy.

Words look simpler and are not. The common shortcut — split on spaces and count the pieces — fails immediately outside English. Japanese, Chinese and Thai do not put spaces between words at all, so splitting on whitespace returns something close to the number of sentences.

Doing it properly means asking the system for real word boundaries, which is what the Unicode segmentation rules define and what a browser exposes through Intl.Segmenter. That handles unspaced scripts correctly, and it also decides the awkward English cases consistently.

Those awkward cases are where two tools most often part company. Is "state-of-the-art" one word or four? Is "don’t" one or two? Does a standalone numeral count? Is an em dash between two words a separator? There is no universally right answer, which is exactly why a count should tell you its rule rather than presenting a bare number as though it were objective.

Social platforms each apply their own arithmetic, and it rarely matches a naive character count. Some count a link as a fixed length regardless of the real URL. Some weight characters by script, so text in Latin script counts differently from the same length in Japanese. Some count an emoji as two.

SMS has the strictest and least forgiving rule. A message restricted to a basic Latin alphabet fits 160 characters per segment; include a single character outside that set — a curly apostrophe pasted from a word processor is the classic culprit — and the whole message switches encoding and drops to 70 characters per segment. One invisible substitution can more than double the cost of a bulk send.

The safe approach with any external limit is to check against the platform itself before committing, and to treat any local count as an estimate that is accurate for plain text and approximate for everything else.

Case conversion looks like the most mechanical operation imaginable and contains one genuine trap: it is language-dependent. In Turkish and Azerbaijani, the uppercase of "i" is "İ" (a capital I with a dot), and the lowercase of "I" is "ı" (a dotless i). Applying English rules to Turkish text produces words that are wrong, and applying Turkish rules to English produces "İNDEX".

German has its own case: the lowercase ß uppercases to "SS" in traditional orthography, so the string gets longer. Any code assuming case conversion preserves length is wrong, and any code assuming it round-trips is also wrong.

Title case is not a Unicode operation at all but an editorial convention, and the conventions disagree with each other about which short words stay lowercase. A tool can only implement one of them; check its rule against whichever style guide you are being held to.