const count = text.trim().split(/\s+/).length;

It works for "hello world". It falls apart the moment real text shows up. Emojis, Chinese characters, hyphenated compounds, contractions, and URLs each break a naive counter in their own quiet way, and the result is a number the user cannot trust. This post walks through the five ways word counting goes wrong and shows how to build a counter that gets it right.

1. The whitespace trap: multiple spaces and newlines

The basic version counts empty strings. "hello world".split(" ") gives ["hello", "", "world"], length 3. Trimming and splitting on /\s+/ fixes this specific case, so most tutorials stop here. But whitespace is the easy part.

2. Hyphens and apostrophes: where one word ends

Is "state-of-the-art" one word or four? Is "don't" one word or two? Every word processor has an opinion, and your users have one too. If you split on whitespace only, "state-of-the-art" counts as one. If you split on every non-letter, "don't" becomes two ("don" and "t"), which is clearly wrong.

A reasonable rule that matches what most editors do: treat apostrophes inside a word as part of the word, and treat hyphenated compounds as one word. A regex with Unicode property escapes handles this cleanly:

const wordPattern = /[\p{L}\p{N}]+(?:['\u2019-][\p{L}\p{N}]+)*/gu;
const words = text.match(wordPattern) ?? [];

\p{L} matches any Unicode letter, not just a-z, so accented characters and non-Latin scripts are covered. The optional group keeps "don't", "l\u2019h\u00f4pital", and "state-of-the-art" as single tokens.

3. Emojis and zero-width joiners

Consider the family emoji: it looks like one character but it is actually seven code points joined by zero-width joiners (U+200D). A counter that splits on whitespace counts it as one word, which is fine. But a counter that tries to be clever and counts "characters" with text.length reports 11. Word counting and character counting are different jobs, and emoji expose every shortcut.

The rule: never count a zero-width joiner or a variation selector as a word boundary. If you use the regex above, emoji sequences are simply not letters, so they are skipped. That is the correct behavior for a word counter. If you also need an accurate character count, count grapheme clusters with Intl.Segmenter, not UTF-16 code units.

4. CJK text has no spaces at all

This is the big one. Chinese, Japanese, and Korean text does not use spaces between words. A whitespace-based counter reports an entire Chinese paragraph as one word. That is not a rounding error; it is completely wrong.

There is no perfect regex answer here, because word boundaries in CJK text require a dictionary or a segmentation model. But a widely used practical convention is to count each CJK character as one word:

const cjkPattern = /[\u4E00-\u9FFF\u3400-\u4DBF\u3040-\u30FF\uAC00-\uD7AF]/g;
const cjkCount = (text.match(cjkPattern) ?? []).length;

Combined with the letter-based matcher for spaced scripts, this gives a counter that behaves sensibly across scripts. It is an approximation, and you should say so in your UI, but it beats reporting "1 word" for a 500-character paragraph.

5. URLs, emails, and numbers

Should "https://example.com/some/path" count as one word or five? Most counters say one, because splitting URLs on punctuation produces nonsense. The regex in section 2 already treats it as one token, since it only splits on characters outside the letter/number/apostrophe/hyphen set. Numbers like "3.14" or "1,000" stay intact too. Just make sure your character classes include \p{N} (any Unicode digit), or "2026" vanishes from the count.

The modern shortcut: Intl.Segmenter

If you target modern browsers, the platform now has a built-in answer:

const segmenter = new Intl.Segmenter("en", { granularity: "word" });
const words = [...segmenter.segment(text)].filter(s => s.isWordLike);
console.log(words.length);

Intl.Segmenter handles locale-aware word boundaries, including scripts without spaces, far better than any hand-rolled regex. It is supported in all current browsers. The catch is older environments: if you need broad compatibility, keep the regex approach as a fallback and feature-detect the segmenter.

Putting it together

A robust client-side word counter is about 30 lines:

1. Feature-detect Intl.Segmenter and use it when available.
2. Fall back to the Unicode-aware regex for letters, numbers, apostrophes, and hyphens.
3. Add the CJK character count for unspaced scripts.
4. Never use String.length for anything the user sees; count grapheme clusters if you show characters.

If you would rather not build this yourself, there are free tools that already handle these edge cases. HandyNest has a free word counter at https://handynest.live/tools/word-counter.html that runs entirely in the browser and deals with Unicode text, hyphenation, and CJK input the way this post describes.

Word counting looks like a solved problem until you test it with real text. Handle these five cases and your counter will agree with the number your users expect, which is the entire job.