How Many Words Per Minute Can You Read?

Somewhere along the way, "the average person reads 300 words per minute" became internet gospel. It is wrong. The best current estimate, drawn from 190 studies, puts adult silent reading closer to 238 words per minute for non-fiction. That gap matters if you write "5 min read" labels, size a talk from a script, or wonder whether a speed-reading app is worth it. This guide walks through the real reading speed numbers for 2026 and how to use them.

#TL;DR

• Average adult silent reading is about 238 wpm (non-fiction), 260 wpm (fiction).
• Reading aloud is slower — roughly 183 wpm — because speech is the bottleneck.
• To get reading time, divide word count by 238 and round up.
• Speed reading past ~400 wpm trades comprehension for speed; it is not free.
• Online, people scan: they read maybe 20% of a page's words.

#How many words per minute does the average person read?

The 300 wpm figure gets repeated because it is round and old. The most rigorous modern number comes from a 2019 meta-analysis by Marc Brysbaert, which pooled 190 studies and more than 18,000 participants to estimate reading rate across conditions.

#Silent reading versus reading aloud

Silent reading is faster than reading aloud, and the reason is physical: when you read out loud, your speech muscles cap the rate. Per Brysbaert's meta-analysis, adults average 238 wpm silently for non-fiction and 260 wpm for fiction, while oral reading averages about 183 wpm. Fiction reads faster than non-fiction because the vocabulary is more common and the sentences carry less new information per word.

#Why the number is 238, not 300

Older estimates leaned on small samples or timed tests where people rushed. The meta-analysis is stricter about what counts as normal, comprehending reading. Most adults reading English silently land in the 175–300 wpm range for non-fiction and 200–320 wpm for fiction. If you see a claim of 500, 700, or 1,000 wpm "with full comprehension," treat it the way you would a diet ad — the comprehension part is doing a lot of quiet work.

#How reading speed changes across readers

Reading rate is not one number for everyone. It shifts with age, language background, and the material itself.

The takeaway: pick a reading speed that matches your audience, not a flattering headline figure. A developer blog full of code and jargon reads slower than a chatty newsletter.

#How to calculate reading time from word count

"Reading time" is just arithmetic once you accept a wpm number. The formula is the same one every "X min read" badge uses under the hood.

#The reading-time formula

Reading time in minutes equals word count divided by words per minute:

minutes = wordCount / wordsPerMinute

At 238 wpm, a 1,000-word post is about 4.2 minutes and a 2,500-word deep dive is about 10.5 minutes. Most sites round up to a whole minute so the label never promises less time than the read actually takes.

#A reading-time function in JavaScript

Here is the whole thing in a few lines. Paste text, get a rounded estimate:

function readingTime(text, wpm = 238) {
  const words = text
    .trim()
    .split(/\s+/)
    .filter(Boolean).length;
  const minutes = Math.ceil(words / wpm);
  return `${minutes} min read`;
}

The split(/\s+/) call splits on any run of whitespace, and filter(Boolean) drops the empty string you get when text starts with a space. This is the same word-counting logic behind the iKit Word Counter, which shows live word, character, and reading-time counts as you type.

#Why your estimate should match the content

A single global wpm is a rough tool. Dense technical writing, tables, and code slow readers down, so a 238 wpm estimate can undersell a hard article. If you want an honest label, drop the assumed speed to around 200 wpm for reference-heavy or technical material, and keep 238–260 for narrative prose. Need sample text to test a layout at an exact length? Generate it with a Lorem Ipsum generator instead of guessing.

#Does speed reading actually work?

This is the question the whole topic is really about, and the research answer is refreshingly blunt.

#The speed-accuracy trade-off

A 2016 review titled "So Much to Read, So Little Time," published in Psychological Science in the Public Interest, examined decades of reading research and found little support for speed reading as a shortcut to understanding large volumes of text. The core finding is a trade-off: past a certain rate, going faster means either skipping words or comprehending less. Your eyes are not the bottleneck — language processing is.

#What RSVP and speed-reading apps really do

Apps that flash one word at a time (RSVP, or rapid serial visual presentation) remove the time your eyes spend moving between words. That buys a modest speed-up, but it also removes your ability to glance back at a word you did not quite catch — and re-reading is something skilled readers do constantly. On difficult text, taking away that safety net hurts comprehension more than the eye-movement savings help.

#The one thing that reliably helps

The review's practical note is almost anticlimactic: the most dependable way to read faster is to know more words. The more often you have seen a word, the faster you recognise it, so wide reading and a bigger vocabulary quietly raise your rate over time. No app required. If you want to check your own baseline, time yourself on a passage of known length and divide:

yourWpm = wordsInPassage / minutesTaken

#How fast do people read online versus on paper?

Reading speed on a screen is only slightly slower than on paper. The bigger story online is that people barely read at all — they scan.

#Users read about 20% of a page

Nielsen Norman Group analysed real browsing sessions and modelled how much text a visit allows for. Their conclusion: on an average web page, users have time to read at most 28% of the words if they do nothing but read, and about 20% is the realistic figure. NN/G uses 200 wpm as a baseline assumption, or 250 wpm for highly literate audiences — close to Brysbaert's lab numbers, which is reassuring.

#Scanning is the default behaviour

Because attention is scarce, readers skim for the parts that answer their question and skip the rest. That is why the practical moves for online writing are:

• Put the answer first, before the wind-up.
• Use headings that state what the section delivers.
• Keep paragraphs short so the eye has landing spots.
• Front-load each paragraph with its point.
• Use lists and tables for anything scannable.

#Writing for skimmers without dumbing down

Writing for scanning is not the same as writing less; it is writing so the important 20% is easy to find. Drafting in a distraction-free editor helps you see structure as you go — a live-preview Markdown editor shows your headings and lists rendering in real time, which makes weak structure obvious before you publish.

#How long does it take to read a given number of words?

Once you trust a wpm figure, you can answer the practical question directly: how long is this thing to read? The table below uses 238 wpm and rounds up, the same convention most "min read" badges follow.

#Reading time by content length

These are silent-reading estimates. If the same words are meant to be read aloud — a script, a voiceover, a keynote — slow down to roughly 130–150 wpm, because a comfortable speaking pace is well under silent reading speed. A 1,000-word script that "reads" in 5 minutes will take closer to 7 minutes to say out loud.

#Turning the numbers into a habit

The useful move is not memorising any single figure but building a quick instinct: word count divided by about 240 gives silent reading minutes, and dividing by about 140 gives speaking minutes. Pair that with an accurate live word count and you can size an article, a talk, or a caption before you write a second draft.

#References

• How many words do we read per minute? A review and meta-analysis of reading rate — Brysbaert 2019; source for the 238/260/183 wpm averages and per-group ranges.
• How Little Do Users Read? — Nielsen Norman Group; online reading assumptions (200/250 wpm) and the 20–28% "read" figures.
• So Much to Read, So Little Time — Rayner et al. 2016; the speed-reading review and speed-accuracy trade-off.

#Related on iKit

• The word counter's reading-time readout comes straight from this 238 wpm math — how live word, character, and reading-time counts are calculated in the browser.
• A live-preview Markdown editor makes structure visible while you draft for skimmers — why real-time rendering helps you write scannable, front-loaded content.