Skip to content

Word Counter — Count Words, Characters & Sentences Online

Last verified May 2026 — runs in your browser
0
Words
0
Characters
0
Characters (no spaces)
0
Sentences
0
Paragraphs
~0 min
Reading time

Word & Character Counter — Count Text Online Free

Paste an article draft, blog post, essay, or email and the page breaks it down into six numbers — total words (whitespace-split), characters with spaces, characters without spaces (both Unicode code-point counted, so emoji and CJK count as one each), number of sentences (split on `.`, `!`, `?`), number of paragraphs (split on blank lines), and estimated reading time at the conventional 200 words-per-minute rate. Useful when writing to a target word count for a school assignment, a freelance commission, an SEO content brief, a book review, or a magazine pitch — and helpful for sanity-checking that a long-form draft you just generated with an LLM is actually as long as it claims to be.

About this tool

Words are counted by trimming the input then splitting on `\s+` (any run of whitespace including tabs and non-breaking spaces), which matches what a human means by "word count" for Latin-script text — for CJK, where text isn't whitespace-separated, this counts the entire passage as 1 "word" and you should rely on the character count instead. Characters use the spread-operator iteration trick to count Unicode code points rather than UTF-16 code units, so an emoji counts 1 and a Han ideograph counts 1, matching how Word and Google Docs count. Sentences detect runs of `.`, `!`, `?` — close enough for prose without over-engineering an actual NLP sentence segmenter (it doesn't perfectly handle abbreviations like "Mr." or ellipses "..."). Paragraphs split on blank lines (`\n\s*\n`), the convention prose authors and Markdown editors use. Reading time uses a 200 WPM rate, which is a common-sense average between adult silent reading (~250-300 WPM for fiction) and slow technical reading (~150-200 WPM for academic prose) — `Math.ceil` rounds up so a 199-word piece displays as 1 minute, not 0. Use cases: writing to a target length, checking an LLM's actual output length, prepping a word-limited submission, estimating how long a meeting agenda will take to read aloud.

  • Word count via whitespace-split (handles tabs, non-breaking spaces, repeated spaces)
  • Character count using Unicode code-point iteration (emoji = 1, CJK = 1)
  • Character count both with and without whitespace
  • Sentence count via . ! ? matching
  • Paragraph count via blank-line split (Markdown convention)
  • Reading-time estimate at 200 WPM, rounded up to whole minutes
  • Reactive — all six metrics update on every keystroke
  • Live region (aria-live polite) — screen readers announce changes
  • No upload — your draft never leaves the browser
  • Useful for school work, freelance briefs, SEO targets, LLM output validation

Free. No signup. Your inputs stay in your browser. Ads via Google AdSense (consent required).

Frequently asked questions

Where does the 200-words-per-minute reading speed come from?

The most-cited modern source is Brysbaert (2019), a meta-analysis in Journal of Memory and Language vol. 109 (article 104047) that pooled 190 studies and 18,573 participants. The mean adult silent reading rate for English non-fiction is 238 wpm; for fiction, 260 wpm; with 175–300 wpm typical for non-fiction and 200–320 wpm for fiction. The 200 WPM rate this counter uses sits in the lower band of that range — appropriate for technical, academic, or unfamiliar content where readers slow down, and useful as a defensible single-number estimate when the actual material is unknown. Children, older adults, and second-language readers fall below the average; subject-matter experts can exceed 300 wpm on familiar text.

Why does the word count show '1' for Chinese or Japanese text?

The word counter splits on \s+ (any run of Unicode whitespace), which is the correct behaviour for Latin-script writing systems where words are separated by spaces. Chinese, Japanese, Korean, and Thai don't separate words with whitespace; CJK uses contiguous ideographs and Thai runs syllables together. Real word segmentation for these scripts requires algorithm dictionaries (UAX #29 word boundary segmentation handles some, but Chinese and Japanese specifically need MeCab, Jieba, or similar locale-aware segmenters). For CJK content, the character count is the metric editors and translators actually price by; the word count remains informational for non-whitespace-segmented scripts.

How does this define a paragraph?

Paragraphs are split on blank lines using the regex \n\s*\n, which matches the CommonMark specification — the canonical Markdown grammar (current version 0.31.2, January 2024). CommonMark §4.8 defines a paragraph as one or more consecutive lines of text separated from neighbouring blocks by blank lines; a 'blank line' is a line containing no characters, or only spaces (U+0020) or tabs (U+0009). This convention is what Markdown editors, blog platforms, and static site generators treat as a paragraph break, so the count matches what a writer sees rendered.

How does the sentence count handle 'Mr.' or '...'?

It doesn't, deliberately. The counter detects runs of period, exclamation mark, or question mark — close enough for prose without shipping a full natural-language segmenter (UAX #29 sentence boundary rules plus locale-specific abbreviation lists). Texts with abbreviations ('Dr.', 'Mr.', 'Inc.') will overcount; texts with ellipses ('…wait, what?') may merge sentences. The intent is a useful approximation for word-count workflows, not a research-grade counter. If exact sentence counting matters, the Intl.Segmenter API (granularity: 'sentence') provides UAX #29 segmentation with locale awareness; this counter chose simplicity instead.

How does this counter handle accessibility for screen readers?

All six metrics sit inside a region marked aria-live="polite", the W3C WCAG Success Criterion 4.1.3 Status Messages (introduced in WCAG 2.1, W3C Recommendation 5 June 2018; carried unchanged into WCAG 2.2, Recommendation 5 October 2023) pattern for status updates that should be announced without moving keyboard focus. Polite live regions queue announcements after any speech in progress, which avoids interrupting the user mid-sentence on every keystroke — appropriate for an incremental counter, not for an error or warning. Screen readers (NVDA, JAWS, VoiceOver) consume the live region automatically; users get word-count feedback as they type without losing keyboard focus.

Sources (6)
  • Brysbaert, M. (2019). How many words do we read per minute? A review and meta-analysis of reading rate. Journal of Memory and Language, 109, 104047 (DOI 10.1016/j.jml.2019.104047).
  • MacFarlane, J. (Ed.) (2024). CommonMark Spec, Version 0.31.2. spec.commonmark.org/0.31.2 (released 28 January 2024).
  • ECMA International (2025). ECMAScript 2025 Language Specification — String.prototype [@@iterator] / String Iterator Objects. ECMA-262, 16th edition, June 2025.
  • Davis, M. (Ed.) (2024). UAX #29: Unicode Text Segmentation. Unicode Standard Annex, Revision 45 (Unicode 16.0).
  • The Unicode Consortium (2024). The Unicode Standard, Version 16.0. Unicode Consortium, Mountain View, CA (released 10 September 2024).
  • World Wide Web Consortium (W3C) (2018). Web Content Accessibility Guidelines (WCAG) 2.1 — Success Criterion 4.1.3 Status Messages. W3C Recommendation 5 June 2018; carried unchanged into WCAG 2.2 (Recommendation 5 October 2023).

These are the original publications the formulas in this tool are based on. Locate them by journal name and year on Google Scholar or PubMed.