Content QA: Stop Guessing Word Counts in Editor Review

You push a draft to your team's editor and three days later the comment comes back: "Tighten this to 1,200 words." You open the doc, count by scrolling, estimate from paragraphs, and ship a version that is 1,287 words. Then the editor re-counts with their own tool and tells you it is 1,341. That argument, repeated across a content pipeline, is exactly the kind of friction that quietly erodes trust between writers, editors, and engineering. It also produces inconsistent output: some posts ship under-length, some over, and nobody can reproduce the number.

This article is about the QA side of that workflow — the part where an engineer or technical reviewer needs a deterministic, defensible way to verify that what the writer thinks they wrote is what was actually written, including when the document was edited in a CMS, a static site generator, a Word file, or a pasted-in web form. We will work through the constraints that make "word count" surprisingly slippery, the rules a content QA process can adopt, and the spot in the pipeline where a browser-based counter belongs.

Why "Word Count" Has Three Different Meanings

Counting words sounds trivial until you write a script for it. The plain-English idea of a "word" — a run of letters separated by spaces — is not how most editors and tools actually count. Different systems produce different totals on the same paragraph, and if your QA process does not pick one definition, you will get drift.

The dominant standard in publishing is the definition used by Microsoft Word, which follows the Unicode Text Segmentation rules: a word is a maximal run of word characters between non-word characters, where word characters are letters, digits, and a few punctuation marks like the apostrophe inside "don't." Unicode's UAX #29 defines this segmentation, and it is what most desktop word processors implement by default. If your team uses Word or Google Docs as the source of truth, you are implicitly using this rule.

Two common alternatives diverge from it. First, plain "whitespace splitting" — split on spaces, count the non-empty results. This treats "don't" as one word (good) but also treats "Q3" as one word (fine) while treating "state-of-the-art" as one word (debatable) and "U.S.A." as one word (bad for readability metrics). Second, "token-based" counts used by NLP tools: spaCy's tokenizer, for example, splits punctuation aggressively and treats contractions as two tokens. Comparing a spaCy count to a Word count on the same paragraph can produce differences of 5–10%, especially in technical prose loaded with acronyms, hyphens, and decimal numbers.

A QA process has to pick one and document it. A short policy that fits most teams:

• Use Word-compatible counting for anything that ships to a human reader: blog posts, docs, marketing pages.
• Use whitespace splitting only as a sanity check — it is reproducible in any language with one line of code, so it is useful as a tiebreaker when two counts disagree.
• Never mix counts from different rules in the same review without labeling them.

The Constraints That Trip Up Engineering Reviews

When a content piece moves through a build pipeline, the string the engineer counts is rarely the string the writer pasted into the CMS. Three transformations change the count silently:

1. Markdown to HTML. A header like ## Why It Matters becomes <h2>Why It Matters</h2>. Counted as Markdown, that line is three words. Counted as HTML source, the visible text is still three words, but if your counter naively splits on angle brackets and reads <h2>Why It Matters</h2> as one "word," you will undercount headers throughout the document. The same trap exists for <strong>, <code>, and <a> tags. The fix is to strip tags before counting, or to count the rendered text content the user actually sees.
2. Smart quotes and em dashes. A draft written in Word arrives in the repo with curly quotes (', ", ") and em dashes (—). A naive split-on-whitespace script is fine here. But a tokenizer that treats — as a word boundary will inflate the count for any article that uses em dashes for parenthetical asides, which is most long-form writing. Check your counter on a paragraph full of em dashes before trusting it.
3. Code blocks and inline code. A reader skips fenced code blocks; an editor often should too, because a 200-line JSON example will dominate the word count and distort length-based editorial decisions. But the writer might want the code counted for a tutorial. Decide explicitly and apply the rule consistently.

A reviewer who catches these mismatches is doing real engineering work — the count is data, and data has provenance.

A Reproducible QA Checklist for Editorial Word Counts

Here is a checklist you can drop into a content team's runbook. It assumes the source of truth is the Markdown file in the repo and the shipping format is the rendered HTML page.

1. Confirm the counter rule: Word-compatible (Unicode UAX #29) for reader-facing prose.
2. Count the Markdown source once with code blocks excluded, once with them included; record both numbers in the PR description.
3. Count the rendered HTML text content (after stripping tags) for the same file; it should match the code-excluded Markdown count within 1%. A larger gap indicates hidden characters, smart-paste artifacts, or a counter bug.
4. If the document has tables, count each <td> cell separately. Tables are a common source of off-by-N errors because they pack dense information into short visible space.
5. For docs with front matter, exclude the YAML block from the body count and record its size separately, since the front matter never reaches the reader.
6. If a piece must hit a target range (say 1,200–1,400 words), require two independent counters to agree within 2% before sign-off. Disagreement above that threshold means a tool bug or a copy-paste artifact; stop and inspect.

This is the step where a fast, browser-based counter earns its place in the loop. When a reviewer needs a second opinion on a contested paragraph, or when a writer wants to verify the editor's number before pushing back, opening a practical guide to counting words in an Excel cell without formulas or add-ins is overkill — but for the actual paragraph under review, a tool that runs in the browser, handles curly quotes and em dashes correctly, and shows both the with-code and without-code totals is exactly the right surface. Keep it as a verification step, not the primary counter: the primary counter is the script in CI, and the browser tool is the tiebreaker a human can run in fifteen seconds.

What to Watch For in the Count Itself

Once the tooling is consistent, the QA work shifts to the content. Three patterns reliably produce unexpected counts and deserve an explicit rule.

Acronyms and dotted abbreviations. "U.S.A." is three words by Word-compatible rules but four by whitespace splitting and three by some tokenizers. If your style guide treats it as one abbreviation, your counter rule needs to agree. This is the kind of detail that does not matter for one article and matters enormously across a hundred.

Hyphenated compounds. "open-source," "real-time," "end-to-end" — each is one word in most publication styles, but a split-on-whitespace counter calls them one too, while a tokenizer that splits on hyphens calls them two. Word-compatible counting treats hyphens as word-internal, which matches editorial convention. Confirm your tool does the same.

Numbers. "1,200" is one word in Word; "1,200 words" is two. A tokenizer that splits on commas will call it three: 1, 200, words. This matters in technical writing where the prose is dense with version numbers, parameter values, and decimal quantities.

If you want a defensible position when an editor and writer disagree, the chain of citations to lean on is short: Unicode's UAX #29 text segmentation rules on one side, and on the other side the practical tokenizer behavior in a well-known library. For JavaScript work, the MDN reference on String.prototype.split is enough to implement a sanity-check counter in five lines and confirm that your "whitespace split" total behaves the way you think it does. Two independent references, two domains, same paragraph, same numbers — that is what reproducibility looks like.

Automating the Counter in CI Without Reinventing It

You do not need to write the Word-compatible counter from scratch. Most static site generators already compute word counts during build, and the JavaScript ecosystem has mature tokenizers that follow Unicode segmentation closely. The QA discipline is to capture the number as a build artifact and fail the build if it drifts outside the editorial range.

A minimal approach: add a step in the CI pipeline that runs a small script against the rendered HTML, extracts the text content with the DOM API, applies a Unicode-aware word-segmentation regex, excludes <pre> and <code> blocks by default, and emits the total to a JSON report. The PR comment shows the count alongside the previous build's count, so a reviewer can see at a glance whether the new draft added 40 words or 400. If two PRs land close together and both show large jumps, that is worth a second look; it usually means a copy-paste error, a duplicated section, or a pasted-in spec sheet that should not be in the body.

The browser-based counter belongs in the human loop, not the CI loop. CI gives you reproducibility; a human with a counter gives you judgment when the number is surprising — "wait, why did adding one paragraph add 80 words?" is a question only a person can investigate.

Frequently asked questions

Why does my editor's count differ from mine by 5–10%?

Almost always it is a rule mismatch. One of you is using Word-compatible counting (Unicode UAX #29) and the other is splitting on whitespace alone. The most common culprits are curly quotes, em dashes, and hyphenated compounds. Pick the Word-compatible rule for any prose that reaches a reader, and use whitespace splitting only as a sanity check.

Should code blocks be included in the editorial word count?

Usually no for reader-facing prose, yes for tutorials where the code is the content. The QA process should record both numbers and label them, so nobody is surprised when a JSON example pushes a tutorial over its target length.

How do I count the words in a table cell?

Treat each cell as its own document, run the same rule, and add them up. Tables are dense enough that the total is usually lower than a glance suggests, which is why editors sometimes flag them as "too short" when the prose around them is fine.

Can I trust an online word counter with smart quotes and em dashes?

Run the same paragraph through two different counters and compare. If they agree, you have a reliable tool. If they disagree, the paragraph probably contains a character one of them handles poorly — usually a curly quote, an em dash, or a non-breaking space pasted from a CMS. Fix the source and the counts will converge.

---

This article was drafted with AI assistance and reviewed for technical accuracy before publishing.