Word Counter Online: Live Word & Character Counts

You paste a draft, and you need three numbers fast: how many words, how many characters, and how long it takes to read. A good word counter gives you all three live as you type — no upload, no sign-up. This guide covers what those counts actually measure, why JavaScript miscounts emoji, and where the "5 min read" number comes from, so you can trust the figures instead of guessing.

#TL;DR

• A "word" is a run of non-whitespace characters; counting is simple for spaced languages.
• Reading time uses ~238 words per minute, the adult silent-reading average.
• JavaScript's .length counts UTF-16 code units, so one emoji can count as 2.
• Twitter/X allows 280, but CJK and emoji count as 2 each; SMS caps at 160.
• iKit's counter runs in your browser — your text never leaves the device.

#What a word counter actually counts

Every counter shows a handful of numbers, and they do not all measure the same thing. Knowing which is which stops you from trimming a caption to the wrong limit.

#Words vs characters vs characters without spaces

A word is the simplest metric: split the text on whitespace, and count the non-empty chunks. "New York" is two words, "state-of-the-art" is one. Characters counts every symbol including spaces, tabs, and newlines. Characters without spaces strips all whitespace first — useful for some editorial style rules, but not for social or SMS limits, which do count spaces.

When you check a tweet or a text message, always read the with-spaces character number. When an editor says "800 characters, no spaces," use the other one. Mixing them up is the most common counting mistake.

#How reading time is estimated

Reading time is not measured, it is derived: word count divided by an assumed reading speed. Pick 238 words per minute and a 1,190-word post becomes a 5-minute read. That is why two blogs can label the same article "4 min" and "6 min" — they assumed different speeds. More on the real number below.

#Why the count updates live

The count refreshes on every keystroke because the whole thing is a small function running on the text in the box. There is no round trip to a server, which is what makes a browser-based word counter feel instant even on a 10,000-word document.

#How many words per minute can you actually read?

The number you have probably seen — 300 words per minute, sometimes higher — is too optimistic. The research says most people are slower, and that matters if you are labelling content or planning a talk.

#The 238 WPM benchmark

The most careful estimate comes from a 2019 review and meta-analysis of reading rate by Marc Brysbaert, pooling 190 studies and more than 18,000 participants. It puts adult silent reading at about 238 words per minute for non-fiction and 260 for fiction. Oral reading — reading aloud — averages around 183. The often-repeated 300 WPM figure comes from older studies that measured skimming or did not check comprehension.

#Reading time vs speaking time

If you are writing a script, do not use reading speed. People speak far slower than they read silently — roughly 130 to 150 words per minute for a clear, unhurried talk. A 3,000-word script is a ~12-minute read but closer to a 20-minute talk. Word counters that offer a "speaking time" number apply this slower rate.

#Why "5 min read" labels vary

Because the divisor is a choice. Medium historically used ~265 WPM; many blogs use 200 for a comfortable margin. iKit uses 238 to match the best available evidence. None are wrong — they are just different assumptions, which is why the label is a rough guide, not a promise.

#Why your str.length in JavaScript lies about emoji length

Here is where naive character counting breaks. If you build a counter with text.length, it will over-count anything outside the basic multilingual plane — most obviously emoji.

#UTF-16 code units vs grapheme clusters

JavaScript strings are UTF-16. Per MDN's String: length reference, .length returns the number of 16-bit code units, not the number of characters a human sees. Characters above U+FFFF are stored as a surrogate pair — two code units — so a single emoji reports a length of 2:

"😀".length;        // 2  (surrogate pair)
[..."😀"].length;   // 1  (code points)

Combined emoji are worse. A "family" or a flag is several code points joined by zero-width joiners, so .length can report 7 or more for one glyph.

#Counting graphemes with Intl.Segmenter

The fix is to count grapheme clusters — the user-perceived characters. The modern, standards-based way is Intl.Segmenter, standardized in ECMAScript 2022:

const seg = new Intl.Segmenter("en", {
  granularity: "grapheme",
});
const count = [...seg.segment("👨‍👩‍👧")].length;
// count === 1

This handles skin-tone modifiers, ZWJ sequences, and flags correctly. See the MDN Intl.Segmenter reference for the full API.

#What this means for character counters

A counter that reports .length will tell you a one-emoji caption is "2 characters" — technically true in code units, but useless for a human limit. A well-built counter segments graphemes so the number matches what you see. It is a small detail that decides whether your "280 characters" is actually 280.

#Character limits: Twitter/X, SMS, and SEO

Most people open a counter to hit a limit, not out of curiosity. The limits below all count differently, so the same text can pass one and fail another.

#The X 280-character weighted count

X (Twitter) allows 280, but it does not count every character as 1. Per X's Counting characters documentation, CJK ranges (Chinese, Japanese, Korean) and all emoji have a weight of 2. So an all-English post fits 280 characters, but an all-Japanese post fits only 140. URLs are wrapped by the t.co shortener and always count as 23, however long the original.

#Why an SMS over 160 characters costs more

SMS is a hard technical limit, not a style rule. A single message carries 140 bytes. With 7-bit GSM-7 encoding that is 160 characters, as Twilio's SMS character limit guide explains. Add one emoji or a non-GSM accent and the whole message switches to 16-bit UCS-2, dropping the limit to 70 characters. Longer messages are split into segments (153 GSM-7 chars each, after header overhead) and billed per segment — so 161 characters can cost double.

Here is the cheat sheet:

#SEO title and meta description lengths

Search snippets are limited by pixel width, not a hard character count, but character targets are the practical proxy. As a 2026 rule of thumb:

• Title tag: aim for 50–60 characters before Google truncates.
• Meta description: aim for 150–160 characters.
• URL slug: 3–5 words keeps it readable and shareable.

A live counter is faster than reloading a SERP preview for every edit.

#How to count words online without uploading anything

The last question is privacy. Word counts sound harmless, but the text you are counting often is not — unpublished drafts, client contracts, internal memos.

#Everything runs in your browser

iKit's word counter is a JavaScript function that runs on the page. Your text is never sent anywhere; close the tab and it is gone. That is the same client-side model behind the rest of the suite, from the Markdown editor to the case converter. If you need filler text to test a layout, the Lorem Ipsum generator is in the same family.

#Handling CJK and mixed scripts

For Chinese, Japanese, Korean, and Thai, whitespace does not separate words, so a whitespace split under-counts badly. Proper counting segments on word boundaries with Intl.Segmenter set to granularity: "word", then counts the segments the API marks as word-like. Mixed English-and-CJK text is counted per script, which is why a serious counter treats "characters" and "words" as separate, script-aware questions rather than one naive split.

#References

• How many words do we read per minute? A review and meta-analysis of reading rate — Brysbaert 2019; source for the 238 WPM silent-reading average.
• String: length — MDN Web Docs — confirms .length returns UTF-16 code units, not characters.
• Intl.Segmenter — MDN Web Docs — grapheme and word segmentation API used for accurate counts.
• Counting characters — X Developer Platform — weighted counting rules for CJK, emoji, and URLs.
• How long can an SMS message be? — Twilio — GSM-7 vs UCS-2 limits and segment sizes.

#Related on iKit

• Estimating read time inside a Markdown editor — the same word-count-to-reading-time math, applied while you write in Markdown.
• Comparing Markdown editors that show live word counts — which free editors surface live counts and reading time as you type.
• Word-level vs line-level diff — the flip side of counting words: measuring exactly which words changed between two drafts.
• How iKit runs entirely in your browser — the client-side architecture that keeps your pasted text on your own device.