Eight metrics, one shared text box, and eight different definitions of "how much"
Every statistic — characters, characters without spaces, words, lines, paragraphs, sentences, reading time, and speaking time — recalculates on every keystroke from the same textarea, with no debounce and no separate analyze step. Each one answers a genuinely different question about the same text, and a few of them are defined more narrowly than the plain-English name suggests, which matters when checking a value against an external limit.
Characters counts UTF-16 units, not what you would count by eye
The character count is JavaScript's own string length, which counts UTF-16 code units rather than what a person would count as one visible character. Plain ASCII text is unaffected, but an emoji like the rocket in "Ship it 🚀" is stored as a surrogate pair — two UTF-16 units for one visual character — so that string reports a length of 10, not the 9 characters actually visible. Characters (no spaces) is the same measurement with every whitespace character (spaces, tabs, and newlines together) stripped out first, using the same whitespace class rather than only literal space characters.
Why a trailing blank line changes your line count
Lines is a raw split on the newline character, and a raw split has one sharp edge: text ending in a newline produces one extra, empty line in the split result, because everything after the final line break — even nothing — still counts as a line. Paste three lines of text with a trailing blank line at the end and the counter reports four, not three.
Paragraphs works differently and more forgivingly: it splits on one or more blank lines, so text separated by single line breaks (like the lines of a list) stays a single paragraph, and only an actual blank line — two consecutive line breaks — creates a new one. Empty paragraphs from stray blank lines at the start or end of the text are filtered out before counting, so trailing whitespace does not inflate the paragraph count the way it inflates the line count.
Sentence counting is a punctuation heuristic, not grammar
Sentences are counted by matching runs of period, exclamation, and question-mark characters and counting each run as one sentence boundary, regardless of how many punctuation marks are in the run — "Yes!!!" ends one sentence, not three, because the three exclamation marks match as a single run. This is a genuinely naive heuristic: it has no concept of abbreviations, so "Dr. Smith arrived." registers two sentence boundaries for what is actually one sentence, and no concept of decimal numbers, so a price like $3.14 contributes a boundary of its own. It works well for typical prose and poorly for text full of abbreviations or numbers.
Reading time and speaking time: two fixed constants, one word count
Both estimates divide the same word count by a fixed average speed — 200 words per minute for reading, 150 for speaking — with no adjustment for sentence complexity, vocabulary, or anything about the actual content beyond how many words it contains. Anything under a full minute displays in seconds instead of minutes and seconds, rounded to the nearest whole second.
One string, eight numbers, and where the text can travel next
Typing "Ship it today. Are you sure?? Yes!!!" reports 36 characters, 30 without spaces, 7 words, 1 line, 1 paragraph, and 3 sentences — one for the period, one for the double question mark (counted as a single run), and one for the triple exclamation mark (also a single run). At 7 words that is a 2-second read and a 3-second speak by the fixed-speed math above.
Make QR and Encode Base64 both hand the current text straight to another tool's input field through a short-lived, versioned browser-storage relay — capped at 100,000 characters and expiring after 30 minutes — rather than a URL parameter or a server round-trip, so nothing typed here is ever sent anywhere. Pasting over that character cap makes the button show an inline error instead of navigating.