Why Two Word Counters Give You Different Numbers

Paste the same paragraph into three tools and you will often get three numbers. None of them is wrong. "Word" has no single definition a program can apply, so every counter makes a series of small judgement calls, and those calls disagree.

Where the disagreements come from

• Hyphenated compounds. Is "state-of-the-art" one word or four? Splitting on whitespace gives one; splitting on any non-letter gives four.
• Contractions and possessives. Most counters treat "don't" as one word, but a tool splitting on punctuation makes it two.
• Numbers and symbols. Does "42" count? Does "$1,200"? Does a standalone em dash?
• Structure. Word processors often exclude footnotes, endnotes, headers and text boxes by default, and include them when asked.
• Markup. Counting the rendered text of a page gives a very different number from counting its source.

The most common approach — collapse runs of whitespace and count what is left — is simple and predictable, which is worth more than being philosophically correct. A count you can reason about beats one that is subtly clever.

Languages that break the whole idea

Whitespace counting assumes words are separated by spaces. Chinese, Japanese and Thai do not work that way: a sentence runs continuously, and finding word boundaries requires a dictionary and real linguistic analysis. A whitespace counter reports a Japanese paragraph as one or two words.

This is why publishing conventions in those languages use character counts rather than word counts, and why any cross-language comparison of "words" is meaningless without saying which method produced them.

When to count characters instead

Several limits that matter in practice are character limits, and words are the wrong unit for all of them. A meta description is truncated by pixel width in the region of 155 to 160 characters. A page title goes at roughly 60. SMS messages segment at 160 characters, or 70 once any non-Latin character appears.

Character counting has its own ambiguity: an emoji made of several code points may count as one character to a person, two to a naive length check, and more to something counting bytes. Any limit expressed in characters is only well defined once you know which of those it means.

"cafe"    4 characters, 4 bytes in UTF-8
"café"    4 characters, 5 bytes
"cafe\u0301"  5 code points, still looks like café
"👨‍👩‍👧"      1 visible glyph, 8 code points

Reading time, and why it is a rough figure

Reading time is word count divided by an assumed speed, usually between 200 and 250 words a minute for adult silent reading of ordinary prose. It is an estimate built on an average, and the variation between readers is far larger than the variation between tools.

It also degrades badly on technical material. Code blocks, tables and formulae are not read at prose speed — they are scanned, re-read, or skipped entirely. A page that is half code will have its reading time overstated by any counter that includes the code, which is a good argument for excluding it from the count altogether.

Reading time is a courtesy, not a measurement. Its job is to tell someone whether they have time now, and it does that well enough at any reasonable speed.

Which number to trust

Whichever one the person judging your work is using. If an editor specifies 1,500 words and works in a particular word processor, that tool defines the number, however it counts. If a form enforces a character limit, its own count is the only one that matters.

For everything else, consistency beats precision. A single tool applied throughout a project gives comparable numbers across documents, and comparability is almost always what the count was for in the first place.