How to estimate reading time

“5 min read” at the top of an article isn’t just decoration — it sets expectations, improves click-through, and gives readers permission to start. The math is simple (words divided by reading speed) but the details matter: which reading speed, how to count words, how to adjust for images and code blocks, and when to round. This guide covers how publishers like Medium, Substack, and the New York Times compute reading time, the science behind reading-speed averages, and how to handle mixed content correctly.

The base formula

Reading time = word count ÷ words-per-minute

A typical adult reading non-technical content reads at ~240 words per minute. Academic studies cluster around 200-300 WPM for adults reading for comprehension (not speed-reading, not skimming).

Medium uses 265 WPM.

New York Times uses 240 WPM.

Academic research (Brysbaert 2019): 238 WPM silent reading, 183 WPM reading aloud.

Pick one, use it consistently. 240 WPM is the safe middle ground.

What counts as a word

Simplest definition: whitespace-separated tokens.

"hello world foo".split(/\s+/).filter(Boolean).length= 3.

Edge cases:

Hyphenated words: “long-term” — count as 1 or 2? Most counters split on \s+ so it’s 1. Fine either way; don’t overthink.

Contractions: “don’t” = 1 word.

Numbers, punctuation, URLs: each counts as one word if surrounded by spaces.

Don’t count characters divided by 5 (the old typewriter standard) — it’s less accurate for modern prose with mixed word lengths.

Adjusting for images

People don’t read images, but they spend time looking at them. Medium’s algorithm adds ~12 seconds for the first image, decreasing for subsequent ones (3-10s each).

Simple approximation: add 12 seconds per image, capped at maybe 30 seconds total. For articles with heavy visual content, this alone bumps the estimate meaningfully.

Alternative approach: ignore images entirely. If your articles are primarily text, the variance per image is small enough not to matter.

Adjusting for code blocks

Code reads slower than prose — roughly half the speed. A Stanford study found programmers averaging ~100 WPM reading code vs ~250 WPM reading prose.

For articles that mix prose and code:

Option A: Extract code blocks, count words separately, apply 100 WPM to code and 240 WPM to prose. Sum the two estimates.

Option B: Add a flat bump (30 seconds per code block, or 2x the word time for code). Close enough for most cases and simpler to implement.

Option C (publishing default): Ignore the difference. For a typical technical article, the variance is 10-20 seconds, which rounds away.

Rounding and display

Output needs to be usable. “3.47 min read” looks fake.

Always round up to the nearest minute. A 2.1- minute article is “3 min read” — underpromising is better than overpromising.

Articles under a minute: “< 1 min read” or “Quick read.”

Very long articles: some publishers switch to hours. Avoid fractional hours (“2.5 hr read”); say “3 hr read” or break into parts.

Language matters: “min read” is the standard; “minutes to read” is longer but clearer. Medium picked “min read.” It stuck.

When accuracy matters more

For content where time pressure is real:

Audiobooks/podcasts: different calculation — ~150-160 WPM for spoken content. Length in minutes is exact (duration) rather than estimated.

Speech-to-text: generated transcripts inherit the audio duration directly.

Email campaigns: A/B tests show promised reading times (“3 min read”) boost open-to-click rates ~10-15%. Overpromising (“1 min” on a 5-min read) hurts trust.

Non-English content

Reading speeds differ by language:

English: 238 WPM.

French: ~214 WPM.

Spanish: ~218 WPM.

Chinese: ~158 CPM (characters per minute, not words — Chinese doesn’t use spaces).

For Chinese/Japanese, count characters instead of words. Typical rate: 300-400 Chinese characters per minute.

Reading level and complexity

Readers slow down on dense academic prose or unfamiliar technical material. Flesch-Kincaid grade 12+ text is read roughly 20-30% slower than grade 8 text.

Most publishers ignore this — estimates are rough by design. If you need precision, pair reading time with a readability score (Flesch, Dale-Chall) so readers see both.

Putting reading time where it helps

Top of article: standard placement. Medium, Substack, New York Times — all put it near the byline.

In the preview card: on a list of articles, reading time helps readers pick what fits their available time.

In email newsletters: “5 things, 8 min read total” performs well.

Schema.org markup: the timeRequiredproperty on Article lets search engines display reading time in rich results. timeRequired: "PT5M" in ISO 8601 duration format.

Common mistakes

Using 200 WPM (too slow). Modern adult readers exceed that. 200 WPM overstates reading time. Use 240-265.

Counting HTML or markdown syntax. Strip the markup first. <strong>text</strong> is one word (“text”), not three tokens.

Showing 0 min. Always floor at “< 1 min read” or “1 min read.” Never display zero.

Counting words in comments or related-post sections. Only count the article body itself.

Hard-coding the estimate. Compute it from the content at build/render time so edits update the display automatically.

Run the numbers

Paste any text into the reading time estimator and get instant word count and minutes. Pair with the word counter for detailed stats including sentences and paragraphs, and the readability score checker to match tone and grade level to your audience.