How to Calculate Reading Time (and Why 200 WPM Is a Lie)

You wrote a 2,000-word article. You need to put a "5 min read" tag on it. Where does that number come from, and is it accurate? Most sites use 200 words per minute as a default, but the real answer depends on your reader, the content type, and whether the reader is skimming or actually reading.

This guide covers the reading-time formula, why 200 wpm is a misleading default, the difference between reading time and speaking time, and how to use the right number for your content. If you just need to calculate, the Uttir Reading Time Calculator does it for free in your browser.

The reading time formula

The formula is straightforward:

reading time (minutes) = word count ÷ words per minute (wpm)

The interesting question is the WPM constant. Different sources use different numbers:

• 200 wpm — the default most calculators use, based on average adult silent reading speed. Reasonable for general content.
• 238 wpm — a slightly more conservative estimate that accounts for re-reading and comprehension pauses. Used by Medium and several reading-time libraries.
• 250–300 wpm — typical for fast readers skimming familiar content.
• 130 wpm — the standard for speaking time, used for podcasts, presentations, and video scripts.
• 100–150 wpm — slower readers, dense technical content, or audiences reading in a non-native language.

For most blog posts and articles, 238 wpm is the right number. It produces estimates that match the average reader's experience, not the optimistic speed of a practiced reader.

Why 200 wpm is a lie

The 200 wpm number comes from studies of adult readers in laboratory conditions with simple prose. Real-world reading is slower because:

• Most readers encounter unfamiliar vocabulary that requires a moment of processing.
• Code blocks, tables, and images interrupt the flow even though they don't add to the word count.
• Most readers re-read sentences to confirm understanding — silent reading is rarely linear.
• Mobile readers (now 60%+ of web traffic) read on smaller screens and scroll back more often.
• Non-native English readers process at 100–150 wpm even when they have full vocabulary.

This is why Medium and a handful of other publications switched from 200 to 238. The 200 number underestimates most readers, which means your "5 min read" is closer to 7 min for the median person. Use 238 for a more honest number.

Reading time vs. speaking time

These are two different metrics and they should not be confused.

Metric	WPM	Use for
Silent reading	238	Blog posts, articles, documentation
Reading aloud	130–150	Presentations, podcast scripts, video narration
Skimming	400+	Deciding whether to read in detail

The Uttir Reading Time Calculator gives you both numbers. The reading time assumes silent reading; the speaking time is the duration if the same text were narrated aloud at a comfortable pace.

Why this matters: if you're scripting a 5-minute YouTube video, you need ~650 words for spoken narration (130 wpm × 5 min). If you're writing a 5-minute blog post, you need ~1,200 words for silent reading (238 wpm × 5 min). Same "5 minutes," different word counts. Use the wrong number and your script is twice as long as it should be.

How different content types read differently

The base WPM assumes continuous prose. Real content has interruptions.

• Code blocks — reading speed drops to 50–80 wpm. A 30-line code sample that would take 30 seconds to skim takes 2–3 minutes to actually read and understand.
• Tables and charts — most readers spend 10–30 seconds per row, regardless of how many words are in the cells.
• Lists and bullet points — faster to scan than prose, but the user often reads the first 2–3 items and skims the rest. Count the full list in your word count; assume the reader scans.
• Images and diagrams — adds 5–30 seconds per image depending on complexity. Not counted in word count, but the reading time is real.

For technical documentation, the WPM needs to be lower. A common formula is to take 70% of the prose WPM (about 165 wpm) and add 15 seconds per code block. That's outside the scope of a simple word-count tool but worth keeping in mind when you set time estimates on your own writing.

Why the "min read" tag is more useful than it looks

That "5 min read" label is doing more work than you think. It sets expectations — readers decide whether to commit based on the time investment. A wrong number is worse than no number: if the actual reading time is twice what you advertise, the reader feels cheated, and they leave the page faster.

Three rules of thumb:

1. Use a slightly conservative estimate. 238 wpm is better than 200 wpm. If the actual reader takes 6 minutes for a "5 min read" article, they don't mind. If the actual reader takes 8 minutes for a "5 min read" article, they do.
2. Round up, not down. "5 min read" is fine for 4.5–5.5 min. "5 min read" for 3.5 min is dishonest in a way that feels stingy.
3. Show the time, not a range. "5 min read" is clearer than "4–6 min read." Most readers want one number to anchor on.

Reading time for accessibility

Reading time is a useful accessibility signal for users with cognitive disabilities, attention differences, or non-native language skills. Showing the time helps them budget their attention. The Uttir Reading Time Calculator shows both reading and speaking time, which helps people with dyslexia or visual impairments plan their listening time too.

W3C's WCAG guidelines don't mandate reading time labels, but they do recommend "sufficient time" for reading content. A reading time tag implicitly supports this by telling the user how much time they're committing to.

FAQ

Is 200 wpm or 238 wpm better?

238 wpm is more realistic for general content. Use 200 if you want optimistic numbers, but most readers will find your "5 min read" articles take closer to 6–7 minutes at 200 wpm. The Medium standard is 238 wpm.

What about speaking time for podcasts?

Use 130 wpm for conversational narration, 110 wpm for clear educational content, 150 wpm for energetic delivery. The Uttir Reading Time Calculator uses 130 wpm as the speaking default — a comfortable pace for most voice work.

Should I count code blocks?

For a quick word-count-based estimate, yes. For an honest reading-time estimate, treat code as taking 2–3× longer per word than prose. A 100-word code block might take 1–2 minutes to read, not 25 seconds.

Does the WPM change for different languages?

Yes — but English is the baseline at 238 wpm. Chinese and Japanese read at lower WPM but cover more information per character. Spanish and Italian read faster than English. German tends to read slower because of compound words. The numbers shift by 10–20%, but the formula stays the same.