DEV Community

Cover image for What's the Average Reading Speed? 238 WPM, and How to Measure Your Own Honestly
Mr.Rain
Mr.Rain

Posted on Originally published at lumenread.net

What's the Average Reading Speed? 238 WPM, and How to Measure Your Own Honestly

Quick answer before any code: the average adult reading speed in English is about 238 WPM for nonfiction, 260 WPM for fiction, and 183 WPM reading aloud — from a 2019 meta-analysis of 190 studies. If your homemade WPM meter says you read 600, the meter is more likely broken than you are exceptional. This post covers what the benchmark actually measures, the three ways reading-speed tools lie, and how to build an honest one in a few dozen lines.

Terminal mockup: measuring reading pace — 1,240 words in 5 minutes 12 seconds of active time equals 238 wpm, right at the adult average

Where the 238 WPM number comes from

In 2019, Marc Brysbaert published a meta-analysis of reading-rate research in the Journal of Memory and Language — 190 studies pooled into reference numbers per reading mode:

Reading mode Average pace Why it differs
Silent reading, nonfiction 238 WPM Reading for understanding — the default "reading speed"
Silent reading, fiction 260 WPM Predictable narrative carries the reader
Reading aloud 183 WPM Speech production caps the pace

Two properties of these numbers matter for how you use them:

  • They are population medians with wide spread, not thresholds. Plenty of healthy adults sit below or above with full comprehension.
  • They are mode-dependent. Quoting "the average reading speed" without the mode and material is like quoting "the average HTTP response time" without mentioning which endpoints.

If you want the full breakdown — age curves, the fiction/nonfiction split, and why Chinese reading speed is a different metric entirely — the full benchmarks article breaks it down.

The three ways WPM meters lie

I've benchmarked a few reading trackers, and nearly every wrong number traces back to one of three bugs:

1. Wall-clock time. The timer runs while you're answering Slack. Your "reading time" inflates, your WPM deflates, and nobody notices. Fair measurement counts active visible reading time — pause the clock when the tab loses focus or the user stops scrolling. This is the single biggest error, and it's pure code.

2. The stopping-point assumption. Dividing total word count by elapsed time assumes the reader finished. If they bailed at 40%, you're computing their speed over text they never read. Use the actual furthest position reached.

3. Segmentation. text.split(" ") is not word counting. It mangles punctuation, em dashes, and — completely — any CJK text. The same article counted by a regex tool and by a proper segmenter can differ by several percent. That's before we even discuss languages without spaces (more below).

Counting words the way browsers do

The platform gives you a proper tokenizer for free: Intl.Segmenter, which implements UAX #29 word boundaries — the same standard browsers use for double-click word selection. If it's good enough for text selection, it's good enough for a WPM meter:

const text = (await Bun.file("article.txt").text()).replace(/\s+/g, " ").trim();

const words = [...new Intl.Segmenter("en", { granularity: "word" })
  .segment(text)].filter(s => s.isWordLike).length;

const minutes = activeReadingSeconds / 60;
console.log(Math.round(words / minutes), "wpm");
Enter fullscreen mode Exit fullscreen mode

Code card: counting words with Intl.Segmenter word-like segments and dividing by active reading minutes

Node 16+, all modern browsers, and Bun support it. isWordLike filters out whitespace and punctuation segments, so "state-of-the-art" and "don't" get counted the way a reader experiences them.

Counting active time like a benchmark study

The measurement-method section of the average-reading-speed research summary makes the same point the meta-analysis data shows: studies that time self-paced silent reading and count only real reading produce the trustworthy numbers. In the browser, that's a visibility listener plus an idle check, roughly:

let activeMs = 0;
let lastTick = performance.now();

document.addEventListener("visibilitychange", () => {
  // pause when the tab is hidden; reading stopped
});

setInterval(() => {
  const now = performance.now();
  if (document.visibilityState === "visible" && userIsReading()) {
    activeMs += now - lastTick;
  }
  lastTick = now;
}, 1000);
Enter fullscreen mode Exit fullscreen mode

Divide segmenter-counted words by that number, and your meter stops lying. One more honesty rule from the research playbook: treat results under ~60 seconds or under 80% completion as low-confidence samples, the same way you'd distrust a benchmark that exited before the warmup finished.

If you read Chinese or Japanese

Then "words per minute" is the wrong unit, and no conversion factor fixes it. Chinese-primary text is measured in CPM — characters per minute, counting Han characters and excluding punctuation and whitespace. Japanese similarly counts Han characters plus kana. A property test for your counter:

function countHan(text: string): number {
  return (text.match(/\p{Script=Han}/gu) ?? []).length;
}
Enter fullscreen mode Exit fullscreen mode

The key discipline is separation: WPM for space-delimited languages, CPM for Han-script languages, and never a fixed ratio between them. Comparing your English WPM to a Chinese CPM number is a category error, not a stat difference. The benchmark guide covers the CPM side in detail.

Bar chart of adult reading benchmarks in dark theme: 183 wpm aloud, 238 wpm nonfiction, 260 wpm fiction

So what's a good reading speed?

The engineering answer: there is no SLA for reading. 238 WPM on typical nonfiction is the reference point, not the bar — a dense spec read at 180 with full comprehension beats a 400 WPM skim you can't recall. The useful "benchmark" is a personal baseline: same kind of text, same purpose, honest active-time measurement, tracked over weeks. If you want to see where you stand against the research numbers — one unpaced read of a reviewed article, no sign-up, quiz optional — the full guide and test are here.

FAQ

Is 200 WPM slow?
Slightly under the nonfiction average and, on its own, meaningless. On dense material with strong comprehension it's a healthy result. Compare sessions on similar material before worrying.

Why is my tracker's number 40% lower than the average?
Almost always wall-clock time or pause handling. Fix the measurement before concluding anything about your reading.

Can I trust speed-reading tools claiming 1,000+ WPM?
The reading research reviewed in the meta-analysis doesn't support dramatic multipliers: past roughly twice the average pace, comprehension degrades faster than speed improves. Skimming is real; "full-comprehension 1,000 WPM" is not.


Cross-post note: this summarizes research written up in full at LumenRead's average reading speed guide — that's the canonical version if you want to cite one link.

Top comments (0)