Word & Character Counter
Live count of words, characters (with and without spaces), sentences, paragraphs, and estimated reading time. Useful for essays, social media posts, SEO meta descriptions, and tweet drafts.
How it works
- 1Paste or typeCounts update as you type.
- 2Read statsWords, chars, time-to-read.
- 3Use the numbersFor essays, posts, SEO metas.
Word counts that matter: SEO, social, academic, and reading time
Length targets across formats
Different formats reward different lengths. **Tweet / X post:** 280 characters max; 71-100 chars get the most engagement. **LinkedIn post:** up to 3,000 characters; ~1,300-1,700 chars performs best. **SEO meta description:** 155-160 characters before Google truncates it. **SEO meta title:** 50-60 characters. **Email subject line:** 6-10 words for highest open rates. **Blog post:** 1,000-2,000 words for SEO competitiveness, but length follows topic.
These are pattern-data benchmarks, not laws. A 50-word post can outperform a 2,000-word one if it's the answer a reader wants. Use the numbers as guard rails, not goals.
Reading speed reality
Academic studies of reading speed converge on ~250 words per minute for prose, ~200 wpm for technical content, ~300 wpm for fiction. A long-form web article of 1,500 words takes the average reader 6-7 minutes. Medium and most blogging platforms compute this estimate the same way.
Speed reading and skimming aren't the same as reading. Comprehension drops sharply above 400 wpm. If you're writing for retention — instructional content, documentation, anything that needs to be remembered — 200-250 wpm is the right model. If you're writing for skim (news headlines, summaries), no estimate matters because readers won't read the body.
Why character count beats word count for some uses
Words vary in length: a sentence of seven words might be 20 or 80 characters. For UI elements with fixed display width — a tweet, a meta description, a button label — what matters is rendered character count, not word count. The same word-count limit can fit or overflow depending on word choice.
Languages with no word separators — Chinese, Japanese, Thai — have unstable word counts. Character count is the only meaningful metric there. This is also why XML/JSON Twitter API responses use character counts, not word counts.
Sentences, paragraphs, and pacing
Average sentence length in modern web prose is 15-20 words. Anything over 25 words tends to feel labored. Anything under 8 words feels choppy. Mixing lengths — short sentences interspersed with longer ones — creates rhythm. Three identical-length sentences in a row sound monotone.
Paragraphs on screen want to be short: 3-5 sentences. Long paragraphs scare readers off; the eye can't find a place to rest. Same content broken into more paragraphs reads faster. Academic and print conventions are longer, but they assume committed readers, not skimmers.
Counting Unicode correctly
JavaScript's `s.length` returns UTF-16 code units, not characters. The emoji 😀 has length 2; the 🇩🇪 flag has length 4 (two surrogate pairs). For human-meaningful counts, use `[...s].length` (which uses code points) or `Intl.Segmenter` (which counts grapheme clusters — what users perceive as a character).
Common bugs from this: chopping a string at a fixed `.length` and producing invalid UTF-16; truncating an emoji to half its bytes and rendering a tofu box; rejecting valid input because the length 'exceeded' a limit that was counting code units instead of characters.
Frequently asked
How is reading time calculated?
Average adult reading speed is ~200 words per minute for technical content and ~250 wpm for casual prose. This tool uses 225 wpm. Speaking pace is ~150 wpm. Times under one minute show as seconds.
What counts as a word?
Any run of non-whitespace characters separated by whitespace. So 'don't' is one word, '3.14' is one word, '#hashtag' is one word. The counter does not strip punctuation or filter stop words.
Why is the Twitter character count different?
X (formerly Twitter) has a 280-character limit, where most non-Latin scripts (CJK, Hebrew, Arabic) count as 2 characters per glyph. This counter uses a simple unicode-aware count without applying X's weighting — it gives an upper-bound estimate.
Get new tools first.
One tool per week. No ads. Unsubscribe anytime.