How Reading Time Is Estimated: The Math Behind the Min Read

Every "5 min read" label on the web is the same arithmetic wearing different clothes: count the words, divide by a speed, round, and ship it. The Reading Time Estimator does that math in the open, with two speeds instead of one — silent reading and speaking aloud — because a blog post and a conference talk consume the same text at very different rates. Once you see the formula, you can argue with the defaults instead of trusting them.

The formula, exactly as computed

Word counting is deliberately simple: a word is any run of non-whitespace characters. Don't is one word, state-of-the-art is one word, and "42" is a word too. No dictionary, no stemming — just text.match(/\S+/g), the same regex split described in How Regular Expressions Work. Then:

seconds = ceil((words / wordsPerMinute) x 60)

The ceiling matters more than it looks. A 37-word paragraph at 200 words per minute takes 11.1 seconds, but the tool reports 12s — an estimate of "0 seconds" would be a lie, so any nonzero text rounds up to the next whole second. Minutes are reported two ways: as a decimal (7.5) and as a friendly label ("7m 30s"), so you can pick whichever your calendar or CMS understands.

A worked example: the 1,500-word post

Say you have drafted a 1,500-word blog post. At the default 200 words per minute for silent reading, that is 1500 / 200 × 60 = 450 seconds exactly — 7m 30s. Now speak it aloud at the default 130 words per minute: 1500 / 130 × 60 = 692.3, which ceilings to 693 seconds — 11m 33s. Four extra minutes live entirely in the speed difference, not the text.

1,500 words:  reading  7m 30s   speaking  11m 33s
  120 words:  reading      36s   speaking      56s

The small example shows the rounding again: 120 words aloud is 55.4 seconds raw, reported as 56s. For short texts the ceiling is a visible share of the total; for long ones it is noise.

Why two speeds — and why 130 for speech

Silent reading for an adult averages around 200-250 words per minute, which is why the default is 200: it is the conservative end of the range, so the estimate errs slightly long. Speaking is a different machine. Presenters are coached to land near 130 words per minute precisely because faster speech stops being comfortable to follow — this is the pace most recorded talks and audiobook narration sit at. If you write scripts, the gap between the two numbers is your editing budget: text that "reads in five minutes" is a seven-minute talk, and a six-minute talk slot needs a script closer to 800 words than 1,200.

Picking a words-per-minute that fits your audience

The rate is an assumption, so change it when the assumption is wrong. Skimmable content read at a hurry deserves 250-300; dense documentation for careful study might be 150-180; young readers are slower across the board. The tool takes any positive number — try your own text at three rates and see how much the label moves. What it will not do is count anything but words: images, videos, headings, and code blocks all disappear unless they contribute tokens. A post that is half screenshots reads faster than its word count says, and a page of code examples reads slower.

Where the estimate goes wrong on purpose

Two simplifications are worth knowing. First, real reading is not constant-rate: readers slow down for lists and formulas and skim connective tissue, so the true time is a distribution, not a number. Second, the count includes everything tokenized — a URL pasted mid-sentence is one long "word" that takes a beat to process but counts like any other. Neither flaw matters for a blog label; both matter if you are timing a rehearsed script, where reading it aloud yourself once beats any formula.

Try it yourself

Paste your draft into the Reading Time Estimator and compare the reading and speaking labels — that gap is the honest cost of turning text into a talk. Check the raw token count with the Word Counter to see words, sentences, and paragraphs in one view, and pull the full statistical picture — including the readability scores that predict whether readers will need that whole estimate — from Text Statistics.