What Counts as a Word? Why Counters Disagree on One Text

Paste one sentence into three word counters and you can get three different numbers. Nobody is broken. They are answering three different questions, all of which are reasonable, and none of which is "how many words are there" in any sense a linguist would sign off on.

Here is a sentence built out of the awkward cases:

Don't over-think it: O'Brien took a 20mg dose.

Eight, nine, nine. The apostrophes turn out to be uncontroversial. The hyphen is the entire argument.

The three algorithms

Split on whitespace

text.split(/\s+/).filter(Boolean).length

Fast, obvious, and what most browser-based counters do. It gets plain English right almost all of the time, and it is wrong in exactly one interesting way: it cannot see inside a token. over-think has no space in it, so it is one word, and so is sharp—focused, and so, as we will get to, is an entire page of Chinese.

Unicode segmentation

The Unicode Consortium publishes an actual specification for where words begin and end², and it is more careful than any splitter you would write by hand. It treats a run of letters and digits as a word, allows certain punctuation to sit inside one, and calls everything else a boundary.

Which is why it keeps Don't and O'Brien whole while cutting over-think in half. An apostrophe between letters is internal. A hyphen is a boundary. 20mg stays a single token because a digit run adjoining a letter run is one word.

In the browser this is Intl.Segmenter³, and it takes a locale, which matters more than it sounds:

function wordCount(text, locale) {
  const seg = new Intl.Segmenter(locale, { granularity: 'word' });
  return [...seg.segment(text)].filter((s) => s.isWordLike).length;
}

Microsoft Word and Google Docs land close to this, which is most of why their numbers disagree with a naive split. They are running a different algorithm, not applying a different definition of "word". Word also counts things a browser tool never sees at all, since it is counting a document rather than a textarea⁵.

Count each part

The one nobody implements and a style authority actually recommends. Split on hyphens as well as spaces, so over-think is two.

The hyphen argument, and who is right

Search for this and you will find the same sentence repeated everywhere: Chicago, AP and MLA all count a hyphenated compound as one word.

Chicago says the opposite.

Asked directly whether 32-year-old should count as one word or three against a word limit, the Manual's answer is to count each word as a word, hyphenated or not, because it would not be fair to score 32-year-old as one while 32 years old scores three¹. It concedes that machine counting makes the single-token answer convenient. It does not endorse it as correct.

So the two most considered authorities here, a Unicode specification and a style manual, arrive at the same answer from opposite directions, and the tool in front of you probably disagrees with both.

That is not a crisis. It is a two-token difference on a 2,000-word essay. But it does mean that if you are near a hard limit, the only count that matters is the one produced by whoever is enforcing it.

Where it stops being a rounding error

English is the easy case, and so is every other language that puts spaces between words: French, Spanish, Russian, Greek. Stay inside those and a whitespace split is fine.

Then there is everything else.

A whitespace splitter does not degrade on Chinese. It returns 1. Unicode segmentation with the right locale gets to 8, which is close to what a native reader would say, because the algorithm falls back to dictionary-driven breaking for scripts that need it.

Arabic and Hebrew sit in between. They use spaces, but prefixes and suffixes attach to stems in ways that make "one word" a judgment call rather than a lookup.

For CJK, most counters give up on words and count characters instead, which is the right call: those writing systems are conventionally measured in characters, and the character is closer to a meaningful unit there than it is in English.

Characters are not simpler, they are just differently hard

If you reach for .length on a JavaScript string you get UTF-16 code units, and anything outside the Basic Multilingual Plane counts as two. "👋".length is 2. Almost nobody would call that two characters.

Three ways a "character" refuses to be one thing:

• é is either one code point (U+00E9) or two (U+0065 plus a combining accent). Identical on screen.
• The four-person family emoji is seven code points welded together by zero-width joiners⁴, and one visible glyph.
• The US flag is two code points, a regional indicator for U and one for S.

The unit that matches human perception is the grapheme cluster, and Intl.Segmenter gives you that too³:

function graphemeCount(text) {
  const seg = new Intl.Segmenter(undefined, { granularity: 'grapheme' });
  return [...seg.segment(text)].length;
}

That returns 1 for the family emoji, which is what a user counting on their fingers would say. Our Character Counter reports graphemes, code points and UTF-8 bytes side by side, because which one you want depends entirely on what you are up against. The social platform limits piece goes through which platform enforces which of those.

Which number to actually use

The algorithm is not the question. The enforcer is.

Submitting against a hard limit. Use whatever the recipient uses, and nothing else. A journal's submission system, a grant portal, a job application form: their count is the only one that exists. If they do not say, assume a segmentation-based count, because that is what Word produces and Word is what most institutions have.

Comparing drafts. Any consistent tool. The delta is the information; the absolute number is noise.

Quoting translation work. Count in the source language and expect the target to move. German typically runs longer than English for the same meaning, and CJK will not compare at all on words, so bill those on characters.

Enforcing a limit in your own UI. Grapheme clusters, always. A user who types one emoji expects it to cost one, and a form that silently charges them two for it feels broken in a way they cannot diagnose.

Sizing a database column. UTF-8 bytes, not characters. A VARCHAR(255) holds far fewer than 255 characters once the content stops being ASCII.

Our Word Counter reports words, characters and lines together so you can see the disagreement rather than trust one number, and Line Counter handles the separate mess of trailing newlines and CRLF if that is the count you are stuck with.

If a tool's number surprises you, do not hand-count against it. Work out which of the three algorithms it is running, and the surprise usually explains itself in one sentence.