Fast, practical, browser-based developer tools
Count words, characters, sentences, paragraphs, spaces, lines, bytes, and estimated reading time instantly. This browser-based text counter is useful for articles, essays, scripts, captions, reports, SEO content, and general writing workflows.
Writers, students, editors, marketers, and developers often need quick text statistics. This tool helps you measure content length, estimate reading time, and validate writing limits instantly.
This word counter works directly in your browser, making it convenient for writing targets, article checks, platform limits, scripts, SEO copy, and editing tasks.
For more details about site usage and analytics, read our Privacy Policy.
Paste or type text into the editor, then watch the stats update instantly as you work.
Words Characters Characters without spaces Sentences Paragraphs Reading time Speaking time Lines Spaces Bytes
Almost every word counter, including this one, defines a word the same simple way: split
the text on whitespace and count the pieces (in JavaScript,
text.trim().split(/\s+/)). That works fine for English and other
space-separated languages, but it quietly rests on an assumption that is not universally
true — that words are separated by spaces.
Chinese, Japanese, Thai, Lao, and Khmer write continuously, with no spaces
between words. Feed a whitespace splitter a Chinese sentence and it counts the whole
sentence as one word. For these scripts the meaningful unit is the character, not
the whitespace-delimited token, and genuine word segmentation needs a dictionary- or
machine-learning-based segmenter. The browser now ships one:
Intl.Segmenter with granularity: 'word' is locale-aware and can
segment CJK and Thai text properly, where a naive split cannot.
If this tool, Microsoft Word, and Google Docs all report slightly different word counts for the same passage, none of them is broken — they simply tokenise differently, and there is no canonical answer to appeal to.
Is mother-in-law one word or three? Is don't one word or two? Is
e.g. or U.S.A. a single token, and how many words is a URL or a
price like $3.50? Every tool answers these edge cases with its own rules, so
two counters legitimately disagree by a few percent on the same text. The takeaway: treat a
word count as an estimate accurate to within a percent or two, not an exact figure, and
don't expect two tools to agree to the last word.
"Character count" sounds unambiguous, but the word character hides three different things. This tool offers a count with spaces and without spaces, because both are useful — social and SMS limits usually count spaces, while some form validators do not.
The deeper subtlety is what counts as one character. JavaScript's .length
counts UTF-16 code units, not user-perceived characters. Most emoji live
outside the basic plane and are stored as a surrogate pair, so a single emoji adds
2 to .length; family or flag emoji built from several joined
code points can add far more. What a human sees as one character is a
grapheme cluster, which you have to count with Intl.Segmenter. This
is exactly why an emoji-heavy tweet hits a length cap sooner than its visible characters
suggest. (Platforms add their own rules on top: X weights some characters differently, and
SMS uses GSM-7 septets but silently drops to UTF-16 — halving the 160-character
per-segment limit to 70 — the moment any non-GSM character, including many emoji, appears.)
A reading-time figure is only as meaningful as the assumption behind it. The usual convention for English prose is a reading speed of about 200–250 words per minute; divide the word count by that rate and round up. This tool uses a words-per-minute model for its reading and speaking estimates.
That method breaks for languages without delimited words. Because you cannot reliably count "words" in Chinese or Japanese, reading speed there is measured in characters per minute instead — commonly in the range of a few hundred characters per minute. Whenever you publish a "5 minute read" badge, state the WPM you assumed, because changing that single number changes the answer: the same article is a four-minute read at 250 WPM and a five-minute read at 200 WPM.
Small formatting artefacts throw off simple counters in ways that are easy to miss. Leading and trailing whitespace, runs of double spaces, and stray line breaks all create empty tokens when you split naively, inflating the word count with items that contain no text.
A robust counter defends against this by trimming the text and
collapsing runs of whitespace before it counts — splitting on
/\s+/ after a trim(), and filtering out empty strings — so a
paragraph with messy spacing still yields the count you expect. It is worth knowing this
when a pasted block of text reports a suspiciously high word count: the culprit is usually
invisible whitespace, not the words themselves.
Because there is no universal definition of a "word," and each tool tokenises
differently. Whether don't, mother-in-law, e.g.,
a URL, or $3.50 counts as one token or several is a choice, not a fact, so
counters legitimately disagree by a percent or two. Treat any word count as an
estimate rather than an exact figure.
These scripts have no spaces between words, so a whitespace splitter counts an entire
sentence as one "word." For them the meaningful unit is the character; real word
segmentation needs a dictionary or ML segmenter such as the browser's
Intl.Segmenter with granularity: 'word'. For a quick, honest
measure of CJK text, count characters rather than whitespace tokens.
It depends entirely on the tokenizer. Some count don't as one word, others
as two; mother-in-law may be one hyphenated word or three. There is no
canonical rule, which is why different tools give slightly different totals for the
same passage.
Because JavaScript's .length counts UTF-16 code units, and most emoji are
stored as a surrogate pair — two code units — so they add 2. Some composite emoji add
even more. The count a human perceives (grapheme clusters) needs
Intl.Segmenter, which is why emoji-heavy text can hit a length limit
sooner than its visible characters suggest.
By dividing the word count by an assumed reading speed — commonly 200–250 words per minute for English prose — and rounding up. For languages without delimited words, like Chinese and Japanese, speed is measured in characters per minute instead. Always state the rate you used, since it changes the result.
Both counts are shown, because both are useful. "With spaces" reflects most social and SMS limits, which count every character; "without spaces" suits validators and fields that ignore whitespace. Check which one your target platform actually enforces before trusting a single number.