Paste the same Markdown document into two different word-count tools and you’ll often get two different numbers — sometimes by a wide margin. Paste it into two different “reading time” estimators and the gap gets even bigger, because now two separate sources of disagreement stack on top of each other: how many words the tool thinks you wrote, and how fast the tool assumes a person reads.

Neither number is “wrong,” exactly. They’re built on different assumptions, and for Markdown specifically, one of those assumptions — whether the tool strips the markup before counting — matters a lot more than most people expect. This post covers how our own Markdown Word Count & Reading Time tool calculates its numbers, how that compares to what a handful of other well-known platforms do, and the practical implications for anyone publishing Markdown-authored content.

The Part Everyone Skips: What Counts as a “Word” in Markdown Source

A naive word counter just splits the raw text on whitespace and counts the pieces. Applied directly to Markdown source, this produces a number that’s subtly wrong in both directions at once:

  • Markup tokens get counted as words. A heading marker (##), emphasis delimiters (**/_), a link’s URL, and the punctuation around an image reference all split into whitespace-separated tokens. A link like [check the docs](https://example.com/very/long/path) naively counts as two “words” — [check and the... — when a reader only sees “check the docs” as three words of prose, and the URL isn’t read as words at all.
  • Some real prose gets undercounted. A sentence broken across multiple soft-wrapped lines inside a blockquote, or text sitting inside a table cell, can get miscounted depending on how the splitter handles the surrounding > or | characters.

The practical effect is that a heavily-linked reference document or a page full of tables and images can show a meaningfully inflated or deflated word count compared to a plain-prose post of the same actual reading length — purely as an artifact of how much Markdown syntax surrounds the words, not because the tool is “buggy.” It’s just measuring markup density, not prose length.

Our tool strips Markdown syntax first — heading markers, bold/italic delimiters, link brackets and target URLs, image syntax — before it counts anything, so the word count reflects the words a reader would actually see rendered, not the raw character soup of the source file. If you’re comparing a word count from our tool against a plain wc -w on the raw .md file, expect them to disagree, and expect the difference to grow with how markup-heavy the document is.

How Our Tool Calculates Reading Time

Once the stripped word count is in hand, reading time is estimated at 238 words per minute — the average adult silent-reading speed for meaningful, non-skimmed text, from a 2019 meta-analysis by Brysbaert et al. that reviewed reading-speed studies going back decades. It’s a plain word-count-divided-by-rate calculation with no adjustments for images, code blocks, or content type, rounded up to the next whole minute (a document estimated at 0.4 minutes still shows “1 min read” — nobody wants to see “0 min read”).

The full stat panel reports ten numbers total: words, minutes to read, characters (with and without spaces), sentences (approximated from sentence-ending punctuation), paragraphs (blank-line-separated blocks, excluding headings and code blocks), headings, links, images, and fenced code blocks. All ten are computed from a single pass over the stripped and structural-element-tagged text, so they stay consistent with each other — the word count you see is the same one the reading-time estimate is based on.

Why Other Tools Give You a Different Number

If you’ve ever seen a “3 min read” badge on a blog post and thought it felt off, here’s why estimates vary so much between platforms — it’s not just a different WPM constant, though that’s part of it:

The words-per-minute assumption itself varies widely. Published estimates for silent reading of average material range from roughly 200 to 275+ WPM depending on the study and the type of content being read (technical or unfamiliar material is read slower than casual prose). Plenty of blogging tools and CMS plugins default to a round number like 200 WPM rather than a research-cited figure, simply because it’s an easy default to ship and adjust later.

Some platforms add fixed time for images on top of the word count, rather than relying on WPM alone. The best-known example is Medium’s publicly documented reading-time algorithm: it adds 12 seconds for the first image in a post, decreasing by one second for each subsequent image down to a floor of 3 seconds per image, on top of a roughly 265-WPM word-based estimate. The reasoning is that a reader’s eye pauses on an image for a real, measurable amount of time that a pure word count doesn’t capture at all — the more images a post has, the more this pushes the total above what word count alone would suggest. Several open-source reading-time libraries (used by a number of blogging platforms and static-site plugins) borrow this same image-time-plus-word-time approach rather than inventing their own.

Some don’t strip markup, or strip it differently. A platform’s reading-time calculator that runs on already-rendered HTML text (stripping HTML tags rather than Markdown syntax) will produce a different word count than one that runs on raw Markdown source and strips Markdown syntax — the two aren’t measuring quite the same input, even when both claim to be counting “the words in the post.”

A few platforms don’t estimate reading time at all, and it’s added manually by the author, via a separate plugin, or not shown at all — so “no reading time badge” doesn’t necessarily mean “short post,” just that the platform doesn’t calculate one.

None of this makes any single number more “correct” than another — they’re all reasonable estimates built on different, defensible assumptions. But it explains why you shouldn’t expect two tools to agree, and why a reading-time badge is a rough signal, not a precise measurement.

Quick Reference: What Varies Between Reading-Time Approaches

Factor What it affects
WPM assumption (commonly 200–275) The baseline word-count-to-minutes conversion; higher WPM = shorter estimated time for the same word count
Markup-stripping before counting Whether Markdown/HTML syntax inflates or deflates the “word” count itself, before WPM is even applied
Fixed per-image time (Medium-style algorithms and the libraries that copy the approach) Adds extra seconds per image on top of the word-based estimate, so image-heavy posts read as longer than their word count alone suggests
Content-type adjustment Some estimators don’t adjust for this at all (ours doesn’t); others informally assume technical/code-heavy content is read slower, though this is far less standardized across tools than the WPM constant itself
Whether reading time is shown at all Some platforms simply don’t calculate or display it, which isn’t itself a signal about post length

Practical Implications for Writers

None of this is purely academic if you’re publishing regularly:

  • Reading-time badges are directional, not precise. Treat “5 min read” as “this will take you a few minutes,” not a literal stopwatch prediction — actual reading speed for any individual reader varies enormously based on familiarity with the topic, whether they’re skimming or reading closely, and whether the content is prose or dense technical material.
  • Word count is still useful as a length gauge, independent of the reading-time conversion — the raw number tells you whether a post is thin (worth expanding) or sprawling (worth tightening), which is a more actionable signal than the derived minutes figure.
  • If you’re comparing counts across tools, check whether markup is stripped. A count taken directly off the raw .md file (e.g., a quick wc -w) will run higher than a count taken after Markdown syntax is stripped, and the gap grows with how link- and formatting-heavy the document is — this is the single most common source of “why don’t these two numbers match” confusion.
  • Structural stats (headings, code blocks, links, images) are often more useful than the word count alone when you’re doing an editorial pass — a post with far more headings than paragraphs might be under-developed per section; one with a high image count but few words of surrounding prose might need more explanatory text around each image.

Use Cases

  • Pre-publish checks: confirm a draft hits a target length before it goes out, without needing to open a separate word processor
  • README and documentation length audits: spot check whether a README has grown unwieldy, or whether a section is too thin to be useful
  • Editorial workflows: use the structural stats (headings, paragraphs, code blocks) alongside the word count to catch under-developed sections, not just short posts
  • Cross-tool sanity checks: if a CMS’s built-in word count disagrees with ours, the tables above cover the most likely reasons why, rather than assuming either number is broken

If you’re checking a document’s length and structure, our Markdown Linter catches heading-hierarchy and formatting issues the word-count stats won’t surface on their own, and the Markdown Live Preview Editor lets you see exactly how the stripped, rendered version of your document looks before you publish. If your document is long enough that navigation matters, our Table of Contents Generator builds one automatically from your headings.