Methodology & Accuracy

Every metric on this site is computed by one small engine of pure functions, and every stage of that computation is documented here — including the places where the output is an estimate and by roughly how much it can be off. The pipeline has three stages: tokenization (finding words), segmentation (finding sentences and paragraphs), and derived metrics (readability, density, frequency, timing) computed from the first two.

Stage 1 — Tokenization: what counts as a word

A word is a Unicode-aware run of letters and digits in which internal hyphens and apostrophes do not break the run. Concretely: "state-of-the-art" and "it's" are one word each, accented and non-Latin scripts count correctly, and numbers count as words. The rule's edges are worth knowing, because they explain most disagreements with other tools:

• "2,500" is two words ("2" and "500") because a comma ends a run, while "3.14" is also two words — but see below for why the period inside it does not end a sentence.
• A URL such as https://example.com tokenizes as three words (https, example, com).
• "e.g." contributes two one-letter words — and, separately, a false sentence break.
• Emoji are not words; they are counted as characters (one per Unicode code point).

Stage 2 — Segmentation: sentences and paragraphs

Sentences split on runs of ending punctuation (. ! ? …) followed by whitespace or the end of the text, and a fragment must contain at least one letter or digit to count. Two consequences follow. First, abbreviations followed by a space over-count: "Mr. Smith arrived." registers as two sentences, a limitation shared by most automated counters and stated here rather than hidden. Second, decimals like "3.14" do not split, because the period is not followed by whitespace. Headings and list items without ending punctuation merge into the following sentence, which matters for readability scoring (below). Paragraphs are blocks separated by one or more blank lines; single line breaks do not split a paragraph.

Stage 3a — Readability: the Flesch formulas and their sensitivity

Reading Ease = 206.835 − 1.015 × (words ÷ sentences) − 84.6 × (syllables ÷ words). Flesch–Kincaid Grade = 0.39 × (words ÷ sentences) + 11.8 × (syllables ÷ words) − 15.59. These are the standard published coefficients — Rudolf Flesch's 1948 Reading Ease and the 1975 grade-level recalibration produced for the US Navy — applied without modification. The coefficients tell you what moves a score: each additional word of average sentence length costs about 1 Reading Ease point, while a rise of just 0.01 in syllables-per-word costs about 0.85 points. Word length, not sentence length, dominates — which is why swapping latinate vocabulary for plain equivalents moves scores faster than splitting sentences. Note the scale is conventionally read as 0–100, but the formula itself is unbounded: extremely dense prose scores negative, and the checker reports that honestly rather than clamping it.

Stage 3b — The syllable heuristic, measured honestly

Syllables are estimated, not looked up: the engine counts vowel groups (a, e, i, o, u, y), subtracts one for a silent final "e" (except "-le" endings, so "table" keeps its two), and never returns less than one per word. Spot-checking the heuristic against dictionary syllabification shows both error directions: "created" comes back as 2 (actually 3, because "ea" merges into one vowel group), while "business" comes back as 3 (actually 2, because the silent "i" is counted). "Beautiful" (3), "readability" (5), and "strengths" (1) come back exactly right. Because a text's score averages over many words, individual miscounts partially cancel, and totals typically land within a few points of hand computation — the same trade-off virtually every automated checker makes. Treat scores as strong signals, not laboratory measurements, and expect small differences between tools that use different heuristics.

Stage 3c — Keyword density and word frequency

Both tools rank words case-insensitively, with two exclusions from the ranking: a fixed list of 74 common English function words (the, and, of, that…) and single-character tokens. Two design decisions matter when comparing against other tools. Density percentages divide by all words — stop words included in the base — so a word appearing twice in 40 words is 5% here even though a tool that strips stop words first would report a higher share for the same text. And there is no stemming: "run", "runs", and "running" rank separately, deliberately, because collapsing word forms would hide exactly the repetition patterns the frequency counter exists to reveal.

Stage 3d — Timing estimates

Reading time divides the word count by 238 words per minute, the adult silent-reading average from Brysbaert's 2019 meta-analysis of reading-rate studies. Speaking time uses 150 wpm, a typical prepared-speech pace. Both are averages over populations and genres: skimmers read faster, technical material reads slower, and spoken delivery of number-heavy text runs long because "2,500" counts as two words yet is voiced as four. The figures are estimates for planning, not stopwatches.

Why tools disagree, and which one is right

Word processors, browsers, and online counters differ at the margins because the margins are genuinely ambiguous — hyphenated compounds, headings, trailing punctuation, URLs. Differences of a few units on long texts are normal and no cause for alarm. When an exact figure is contractual (a strict submission limit), the only counter that matters is the recipient's; ours tells you whether you are close enough to care.

How the engine is tested

The analysis library is pure functions with no DOM dependencies, pinned by automated tests: classic pangram counts, hyphen and apostrophe handling, Unicode and emoji cases, sentence and paragraph edge cases, readability arithmetic against hand-computed values, stop-word and density behavior, and the timing math. The same library runs verbatim on our sister sites WordCntr.com and WrdCntr.com, so a correction verified once applies everywhere. If you believe a result is wrong, the contact page explains what to include — confirmed issues are fixed in the engine and locked in with a new test.

Privacy as a design constraint

Everything you type or paste is processed by JavaScript running locally in your browser. Nothing is transmitted, logged, or stored — there is no server that ever sees your text, which you can verify in your browser's network tab: analysis generates zero requests.