What "reading time" actually measures
Reading time is one of the simplest derived metrics in writing tools. Take the word count, divide by an assumed reading speed in words per minute, and report the result. The assumption — the words-per-minute number — is the only interesting decision the tool makes. Our counter uses 200 words per minute (wpm), which is the median adult silent-reading speed established in reading-research literature for general non-fiction English text.
The result is a useful reference number for several practical questions: how long will it take a reader to get through this draft, will this article fit a 5-minute commute, is this email too long for the recipient's likely attention span. None of these questions has an exact answer; reading time is a directional estimate, accurate within roughly ±50% for any individual reader.
The widget renders the time in a human-friendly format: under one minute as "Xs", under one hour as "X min", an hour or more as "Xh Ym". A 200-word paragraph reads in 60 seconds; a 1,000-word article in 5 minutes; a 10,000-word essay in 50 minutes. These are the orders of magnitude readers should expect.
Why 200 words per minute
The 200 wpm figure comes from a long literature on adult silent-reading speed. The most-cited modern study (Brysbaert, 2019, J. Mem. Lang., "How many words do we read per minute?") synthesises decades of measurements and reports a mean of 238 wpm for non-fiction prose, 260 wpm for fiction, and as low as 100-150 wpm for technical and academic text. The 200 wpm we use sits at a deliberately conservative midpoint — slightly slower than the mean for general prose, faster than the rate for dense technical material.
Other reading-time tools use different defaults: Medium uses 265 wpm, Pocket uses 220 wpm, some academic tools use 150 wpm. There is no "correct" answer; the choice trades off different priorities. We picked 200 wpm because it produces estimates that match most readers' actual experience for the kinds of text people typically paste into a counter (drafts, blog posts, emails, essays, articles).
If your reading speed is materially different from 200 wpm — and most adult readers are within ±25% — you can mentally adjust. Doubling our estimate gives a comfortable upper bound; halving it gives a fast-reader lower bound. For most professional and academic uses, the unadjusted estimate is close enough.
What reading-time estimates are useful for
Three categories of question benefit from reading-time estimates.
Editorial decisions about length. "Is this article too long?" "Does this report fit in the executive summary slot?" "Will the recipient actually read this email?" Reading time gives you a comparable scale across drafts. A 5-minute article is a different beast from a 15-minute one; you can decide which length matches the audience attention budget without counting words manually.
Audience expectation setting. Many publications now display "X minute read" prominently on articles. The number sets the reader's mental commitment. A reader who clicks on a "3-minute read" is annoyed if it takes 10 minutes; a reader who clicks on a "10-minute read" is pleasantly surprised if they finish in 6. Our counter gives you the number to put on the article (rounding to the nearest minute is conventional).
Time-budget planning. "I have 45 minutes during my commute — what can I finish?" "We have a 20-minute meeting; how much background reading can I distribute beforehand?" Time-budget questions translate directly to word-count thresholds via reading-time estimates.
What reading-time estimates are NOT useful for
The 200 wpm estimate fails for several content classes.
Technical / academic / legal text. Dense scientific writing, mathematical equations, legal contracts, and code-heavy technical documentation all read at 100-150 wpm even for fluent specialists. Our 200 wpm estimate underreports the time by 25-50%. For a 1,000-word technical paper that we estimate at 5 minutes, expect 7-10 minutes of actual reading.
Skimming or scanning. Readers who are looking for a specific fact, scanning headers, or speed-reading at 400+ wpm complete text far faster than our estimate. The 200 wpm baseline assumes attentive linear reading.
Visual content. Articles with images, charts, code samples, or interactive elements take longer than the word count alone suggests. A 2,000-word article with five complex diagrams might take 15 minutes despite estimating to 10. Our counter doesn't see the visuals.
Non-prose text. Lists, tables, code blocks, and bulleted reference material read faster than continuous prose. A 500-word reference table might be scanned in 30 seconds rather than 2.5 minutes. Use the estimate as an upper bound for list-heavy content.
Second-language readers. A reader operating in their second language typically reads 30-50% slower than in their first language. If your text targets non-native English speakers, mentally inflate the estimate.
How the calculation works under the hood
The widget runs a simple JavaScript function whenever the textarea content changes:
- Trim whitespace from start/end of the input.
- Split on
/\s+/(any whitespace — spaces, tabs, newlines). - Count the resulting array length — that's the word count.
- Divide by 200 — that's the reading time in minutes.
- Format: under 1 minute → seconds (rounded up to at least 1s); under 60 minutes → "X min" (rounded to nearest minute); 60+ minutes → "Xh Ym".
The split-on-whitespace counting is the universal "word" definition for English-script text. It gives 1 for "hello", 2 for "hello world", 1 for "don't" (apostrophe doesn't separate). For CJK languages where words don't have whitespace separators, the count is closer to a sentence count than a word count — but reading time at 200 wpm doesn't apply to CJK text well anyway, so the mismatch is honest.
Common gotchas
Hyphenated words count as one. "Twenty-five" is one word. "State-of-the-art" is one word. The whitespace-based counter treats hyphens as part of the word.
Numbers count as words. "12345" is one word. "12.5" is one word. "$10,000" is one word. Document length doesn't change much because of this — but if your text is mostly numerical (a table of statistics), the word count and reading time are both lower than the visual content suggests.
Multiple consecutive spaces don't inflate the count. "hello world" has 2 words, not 5. The /\s+/ regex collapses consecutive whitespace.
Empty input gives 0 — not "1 word, 0 seconds". A textarea with only spaces / tabs / newlines counts as 0 words.
The counter doesn't strip Markdown / HTML markup. A draft like **bold word** counts as 2 words ("bold" and "word"), not 1. Reading time inflates accordingly. If your text is heavily marked up, expect the count to be slightly off.
Code blocks count every word inside. Pasted code with comments and identifiers contributes to word count. A 200-line code snippet might add 500 "words" depending on naming conventions.
When a different tool fits better
For per-article reading-time display on a publication, use a Markdown-aware reading-time library like reading-time (npm) — it strips Markdown and HTML before counting and lets you customise the wpm baseline.
For audiobook duration estimation, use a speaking-time tool calibrated for narration pace (typically 150 wpm for audiobook narration, slower than presentation pace).
For podcast script duration, use the speaking-time tool (130 wpm) — it's much closer to spoken delivery than reading time.
For video-script duration, use a per-medium calculator — short-form video scripts run at 160-180 wpm because of editing pace, long-form vlogs run at 130-150 wpm.
For estimating a reader's actual time-on-page in analytics, use the analytics tool's own measurement (Google Analytics, Mixpanel, etc.). Reading-time estimates predict; analytics measure. They often disagree because real reading includes scrolling, distraction, partial reads.
A reference grid for common reading times
Quick mental conversions at 200 wpm:
- 100 words → 30 seconds
- 250 words → 1 minute, 15 seconds
- 500 words → 2.5 minutes
- 1,000 words → 5 minutes (a typical blog post)
- 2,500 words → 12.5 minutes (a long-form article)
- 5,000 words → 25 minutes (a magazine feature)
- 10,000 words → 50 minutes (a thesis chapter)
- 20,000 words → 1 hour 40 minutes (a novelette)
- 50,000 words → 4 hours 10 minutes (a short novel)
- 80,000 words → 6 hours 40 minutes (a typical novel)
Pour your text into the counter for the exact number; use this grid for quick mental ballparking.
A note on the publishing convention
Many publications round reading time to the nearest "X minute read" badge. Common practice:
- Round 0:30 to "1 min"
- Round 4:30 to "5 min"
- Round 9:45 to "10 min"
- Above 60 minutes, switch to "1 hour" / "2 hour" granularity
The widget displays a finer-grain time (with seconds for short text, minutes for longer text). For a publication badge, round to the convention your audience expects.
A final practical observation from working with reading-time estimates day-to-day: the absolute number matters less than the relative number across drafts you are comparing. A draft that estimates to 4 minutes is meaningfully shorter than one that estimates to 7, regardless of whether either reader actually finishes in that time. Use the estimate to make consistent length comparisons across your own drafts; treat the number as approximate when you publish it for an external audience.