What word count actually measures.

Editors ask for "5,000 words." Substack shows a character count. Your writing app splits on whitespace. A Japanese paragraph might count as one word in one tool and forty in another. None of them is lying — they're answering different questions.

Understanding the definitions saves arguments with clients, confusion at submission time, and the subtle privacy mistake of pasting a draft into a server-side counter.

What counts as a word.

The naive definition most browser counters use: split on whitespace, count the tokens. "Hello, world!" → 2 words. Hyphenated compounds usually stay one token (well-known = 1). Contractions with apostrophes usually stay attached (don't = 1).

Microsoft Word and Google Docs add rules you can't see:

• Footnotes and headers may or may not be included depending on view mode
• Text in tables is counted; some online tools strip markup and lose table cells
• Smart punctuation — em dashes, curly quotes — can change token boundaries in edge cases

For fiction and essays, whitespace splitting is usually close enough. For legal or academic work where every word is billable, use the same tool your editor uses and stick to it.

Characters with and without spaces.

Character counts are more stable than word counts — but still not universal:

Metric	Typical use	Gotcha
Characters (with spaces)	Twitter-era limits, SMS, ad copy	Includes newlines; some tools normalize CRLF → LF
Characters (no spaces)	Translation pricing, CJK density checks	Unicode combining marks may count as separate code units
Bytes (UTF-8)	API payload limits, database columns	Emoji and CJK use more bytes than Latin letters

JavaScript's string.length counts UTF-16 code units, not graphemes — so some emoji count as 2. A proper grapheme count needs Intl.Segmenter or equivalent. For English prose the difference is rare; for emoji-heavy social copy it matters.

Reading time and WPM.

Most "X min read" badges assume 200–250 words per minute for adult silent reading of general prose. Technical docs run slower; skimmable listicles run faster.

The formula is boring: minutes = word_count / wpm, rounded up. Some sites add a fixed overhead for images (e.g. +12 seconds per image). That's editorial guesswork, not science.

Sentences and paragraphs are counted differently too — usually split on . ! ? for sentences and blank lines for paragraphs. Abbreviations like Dr. and decimal numbers like 3.14 create false sentence breaks unless the counter is smart about them.

CJK and mixed scripts.

Chinese, Japanese, and Korean don't separate words with spaces. A whitespace splitter treats an entire paragraph as one "word." Correct segmentation needs a dictionary or ML model — which is why Word's Japanese word count differs from a naive browser script.

Mixed-language documents (English body + Japanese quotes) will confuse any single rule. For CJK-heavy work, trust tools built for that script, not a generic counter.

Why client-side counting matters.

Many "free word counters" are server-side: you paste text, it uploads, they count on their backend. For a blog post that's fine. For an unpublished manuscript, a legal brief, or internal strategy doc — that's your draft on someone else's disk.

A browser-only counter (like the Word Counter on this site) runs JavaScript locally. Nothing leaves the tab unless you copy it out. Same privacy argument as what client-side actually means — verify in DevTools: no POST with your text body.

Takeaways.

When someone says "how long is it?" — ask whether they mean words, pages (another convention: ~250 words/page in publishing), or minutes. Those three rarely agree.