Methodology & Accuracy

This page states exactly how WordCntr.com counts — not in general terms, but rule by rule, with the worked examples and known failure cases. If a count here ever differs from another tool's, the explanation is almost certainly in one of the conventions below.

Each rule also has a longer guide with more worked examples, in the order the sections below follow: what counts as a word, characters, code points and emoji, letters and Unicode normalization, sentences, paragraphs and lines, case conversion rules, reading time and words per minute, speaking time and speech length, and how the word finder matches letters to words. The guides index lists them all. This page is the short form: the rule, one example the engine computes when the page is built, and the known failure case. The worked-example figures below are computed by the engines when the site is built, not typed in, so the copy cannot drift from the code.

One paragraph, every counter

Run this text through the site: "Dr. Smith arrived at 9 a.m. She left early." The engine reports 10 words, 43 characters (35 without spaces), 3 sentences, and 1 paragraph. Each number follows from a stated rule. "Dr", "Smith", "arrived", "at", "9", "a", "m", "She", "left", "early" are the ten word-tokens — "a.m." splits at its periods because periods never join tokens. The characters are Unicode code points, spaces and punctuation included. The sentence count is 3 rather than the human answer of 2 because "Dr." — a period followed by a space — triggers the sentence rule; that over-count is a documented limitation, not an accident. And with no blank line anywhere, everything is one paragraph. Its reading and speaking times both display as "under 5 sec": ten words do not fill the smallest span the duration formatter reports.

Words

A word is an unbroken run of Unicode letters, digits, apostrophes (straight or curly), and hyphens. In consequence: "it's" and "state-of-the-art" are one word each; accented and non-Latin text counts correctly; "2026" is a word; "3.14" is two words (the period splits); and a pasted URL like https://example.com/guide/counting contributes five word-tokens, because colons, slashes, and dots all separate. Emoji, em dashes, and ordinary punctuation are never words, with one documented quirk: because hyphens and apostrophes are word characters, one of them standing completely alone (a bare "-" used as a list bullet, for example) registers as a token. The unique-word figure used elsewhere on the site compares words case-insensitively, so "The" and "the" are one entry.

One sentence with every rule in play: "Ana's well-known 2026 report weighs 3.14 kg; see https://example.org/data/notes now." is 15 words. "Ana's" and "well-known" are one token each, "2026" is one, "3.14" splits into two at its period, and the address alone contributes 5 tokens — "https", "example", "org", "data", "notes" — because the colon, the slashes, and the dot all separate. A reader tallying by eye would treat the address as one item and the decimal as one, which is exactly where the gap between the engine's figure and a human count comes from. The stray-hyphen quirk is just as easy to reproduce: "- tea↵- toast" is 4 words, while the same items without their hyphens, "tea↵toast", is 2; the difference of 2 is one token per bare hyphen. And "Count the count, then count again." is 6 words but 4 unique words: "Count" and "count" merge because comparison is case-insensitive, and nothing else does — there is no stemming and no apostrophe stripping, so "count" and "counts" would stay separate.

Characters

Characters are Unicode code points: é is one, 👍 is one, 👍🏽 is two (base plus skin-tone modifier), a flag is two, and joined sequences like family emoji are five or more. Line breaks and spaces each count as one. Note that some platforms count UTF-16 code units instead, which makes most emoji cost two there — the same text can legitimately have two different "character counts" under the two conventions, which matters near a strict limit.

In practice: "Bye for now 👋" is 13 code points, and "Bye for now 👋🏽" — the same words with a skin-tone modifier on the emoji — is 14, because the modifier is its own code point riding on the base. Counted in UTF-16 code units, the same two strings measure 14 and 16: the base emoji and the modifier each need a surrogate pair there, so each costs two. A flag such as 🇨🇦 is 2 code points (a pair of regional-indicator symbols) and 4 UTF-16 units. The UTF-16 figures on this page are taken from the engine's SMS analysis, which counts in those units once a text leaves the GSM alphabet — the next section explains when that happens.

SMS segments

The shared engine includes an SMS length model that follows GSM 03.38, the specification behind text-message encoding, and it is the one place on the site where a count is neither code points nor words. The rule has two branches. If every character in the text belongs to the GSM-7 alphabet — the basic Latin letters, digits, and common punctuation, plus a small set of accented and Greek letters — the message is GSM-7 encoded and each character costs one septet, except the extended characters (the euro sign, square and curly brackets, backslash, caret, tilde, vertical bar, and form feed), which cost two because they are sent as an escape code plus the character. A single GSM-7 segment holds 160 septets; once a message needs more than one segment, every segment carries a concatenation header and holds 153. If any character falls outside that alphabet — an emoji, a curly quotation mark, most non-Latin scripts — the entire message switches to UCS-2, in which a single segment holds 70 units and a concatenated one 67, counted in UTF-16 code units, so most emoji cost two.

Worked through: "Running late, order without me." is 31 septets in GSM-7, 1 segment, with 129 septets to spare. "Split it 50/50 {maybe} and pay in €." is 36 characters but 39 septets: the two curly brackets and the euro sign each cost two, adding 3. "Running late, order without me 🙂" — the first message with one emoji appended — is 32 code points, yet the emoji forces UCS-2, so it measures 33 UTF-16 units against a single-segment capacity of 70 instead of 160. Repeating the first message 6 times, joined by spaces, gives 191 characters and 191 septets — past the single-segment capacity, so it splits into 2 segments of 153 with 115 septets left in the last. Append the emoji to that long text and it becomes 194 UTF-16 units in UCS-2, 3 segments of 67 with 7 to spare.

Two things the model deliberately does not do. It does not know how any carrier or sending platform bills, delivers, or displays segments, and it does not model platform-specific rewriting of links or characters — it reports encoding and capacity exactly as the specification defines them, and nothing more. The per-segment capacities quoted above are the engine's own constants, read from that specification; they are not a limit set by any messaging service, and this page makes no claim about how any service applies them. Empty text is 0 segments, because there is no message to send.

Letters

The letter counter counts only code points Unicode classifies as letters — any script, not just A–Z — with digits, spaces, and punctuation tallied separately so the four buckets always sum to the character total. Text is normalized to Unicode NFC first: an é encoded as e plus a combining acute becomes the single composed letter é before counting, so the two visually identical spellings agree. The honest edge: a combining mark with no composed form survives normalization as its own non-letter code point and is counted under punctuation & symbols, not merged into the letter it rides on. Because of that normalization, the letter page's character total can be slightly lower than the character counter's raw code-point count on decomposed input — each page states which convention it uses.

Worked through: "Room 12B: café, 2 seats." is 24 characters in total — 14 letters (the é among them), 3 digits, 4 spaces, and 3 punctuation and symbol code points (the colon, the comma, and the full stop) — and the four buckets sum back to the total. The normalization step is visible on a single word: "café" typed with a precomposed é is 4 raw code points on the character counter, the same word arriving as e plus a combining acute is 5, and the letter counter reports 4 letters and 4 characters for both spellings once NFC has merged the pair.

Sentences

A sentence boundary is a run of . ! ? or … followed by whitespace or the end of the text, and a candidate segment must contain at least one letter or digit to count. This handles ellipses, "?!" runs, and decimal numbers correctly ("Pi is 3.14 exactly." is one sentence), but it cannot tell an abbreviation from a full stop: "Dr.", "e.g.", and "U.S." each add one phantom sentence when they occur mid-sentence. That bias is always upward and typically small; the words-per-sentence average dilutes it further on any text longer than a paragraph. The one construction that runs the other way is a period followed by a closing quotation mark or bracket rather than whitespace: the character after the period is then the mark, not a space, so no boundary is cut there, and "She said "Stop." Then she left." counts as 1 sentence where the same words with the period outside the mark, "She said "Stop". Then she left.", count as 2.

Worked through: "We met Prof. Lee at noon. She agreed, e.g. on price. Done!" counts 5 sentences, because "Prof." and "e.g." each end in a period followed by a space. Spell the abbreviations out — "We met Professor Lee at noon. She agreed, for example, on price. Done!" — and the engine reports 3, the count a reader would give; the difference of 2 is exactly one phantom sentence per abbreviation. The over-count also drags the words-per-sentence average down, from 4.3 to 2.6 on this text, which is why that average is most trustworthy on prose with few abbreviations and many sentences. There is no abbreviation list to fix this, deliberately: any list would be incomplete, would vary by language and field, and would turn a predictable rule into an unpredictable one.

Paragraphs

Paragraphs are blocks separated by one or more blank lines — the plain-text and Markdown convention. A single line break does not split a block (addresses and verse stay whole), and a line containing only spaces counts as blank. Word processors count paragraph marks instead, so their figure can differ in both directions; the paragraph counter page walks through the copy-paste cases where the two conventions diverge.

Worked through: the short letter "Dear Ms. Reyes,↵14 Harbour Row↵↵Thank you for the quick reply.↵ ↵Best,↵Dani" — shown with ↵ at each line break — is 3 paragraphs. The address line under the greeting is joined to it by a single break, so the two lines form one block; the empty line before the body opens a second; and the line before the sign-off holds only spaces, so it is treated as blank and "Best," plus the name form a third. The same text is 7 lines, 5 of them non-empty — the raw material a paragraph-mark convention works from, which is how it can arrive at a different figure for the identical text.

Lines

Lines split on newline characters, with Windows CRLF pairs and lone carriage returns first normalized to a single break so the originating platform cannot change the count. A trailing newline terminates the final line rather than opening an empty extra one — "a↵b↵" is 2 lines — which matches wc -l, the POSIX definition of a line, and editor line numbering. A line containing only whitespace counts as a line but is classified blank; non-empty plus blank always equals the total. Empty text has zero lines. The line counter page covers the code-and-logs cases these rules are designed around.

Worked through: "alpha↵beta↵" is 2 lines, and the same two lines saved with Windows line endings — a carriage return plus a newline at each break — are also 2, because the pairs are normalized before splitting. Add one more newline, "alpha↵beta↵↵", and the count is 3: the first trailing newline terminates "beta", the second opens a genuinely empty line, reported as 1 blank and 2 non-empty. Empty text, with no line to terminate, is 0 lines rather than one empty line. The letter in the paragraphs section is 7 lines, 2 of them blank — one truly empty, one holding only spaces — which is the distinction between blank and non-empty that a paragraph count relies on.

Case conversion

The case converter offers five transforms, each with a stated rule. Title Case is the simple convention: the first letter of every word is capitalized and the rest of the word lowercased, where a word is the same token the word counter uses — letters, digits, apostrophes, and hyphens run together — so "it's" becomes "It's" and "state-of-the-art" gets exactly one capital. The capital lands only when no digit precedes the first letter of the word: "3rd edition" becomes "3rd Edition" (the digit-led "3rd" stays lowercase), while a leading apostrophe still capitalizes ("'twas" → "'Twas"). There is no minor-word list: editorial styles (AP, Chicago) lowercase words like "of" and "the" mid-title, and this tool deliberately applies no such rules, so every word is treated alike. Sentence case lowercases everything, then capitalizes the first letter of the text, the first letter after a sentence-ending run (. ! ? …) plus whitespace, and a letter that directly opens a new line after any leading whitespace (a line that begins with a bullet or a digit gets no capital from that rule) — which inherits the sentence rule's abbreviation limitation: "dr. smith" becomes "Dr. Smith" with a capital a human editor would not add. aLtErNaTiNg case alternates per letter starting lowercase; non-letters pass through without advancing the alternation ("a b!c" → "a B!c"). One locale caveat, stated honestly: all transforms use the default Unicode (English) case mappings, so café uppercases to CAFÉ, but Turkish's dotless ı / dotted İ distinction is not applied — "i" always uppercases to "I", which is wrong for Turkish text under Turkish rules. These transforms live in a small module local to WordCntr.com (not the shared three-site counting engine), pinned by the same automated test suite.

All five transforms on one line — "it's the 3rd well-lit room; o'neil's desk is by the door. ask for 'kay'." — as the converter produces them at build time, with each rule in the tool's own words:

What to notice. Title Case capitalizes "It's" once, leaves the digit-led "3rd" lowercase, gives "well-lit" a single capital, capitalizes "The", "Is", "By", and "For" like any other word, and capitalizes through the leading apostrophe of "'kay". Sentence case leaves "o'neil's" lowercase mid-sentence — it marks sentence starts, not names — and starts "Ask" fresh after the full stop. aLtErNaTiNg advances only on letters, so the apostrophes, the digit, the semicolon, and the spaces pass through without flipping the pattern. The Turkish caveat in one word: "istanbul" uppercases to "ISTANBUL", with a plain capital I where Turkish orthography wants the dotted İ.

Reading and speaking time

Reading time is the word count divided by 238 words per minute, the average adult silent-reading rate for non-fiction in Brysbaert's 2019 meta-analysis of reading-rate studies — chosen because it is a defensible single published figure, not because any individual reads at exactly that speed. Speaking time divides by 150 wpm, a common prepared-delivery pace. Both are estimates of the middle of a wide range; the reading-time page details when to round up or down.

Worked through: the paragraph "The ferry leaves at seven, so pack the night before: tickets, a charger, the folded map, and the letter for the harbour office. If the morning is foggy, the crossing takes longer and the café on board stops serving early, so eat first. Nobody minds a late arrival, but everyone minds a missed boat." is 54 words. Silent reading is 54 ÷ 238 ≈ 0.23 minutes, displayed as "14 sec"; aloud it is 54 ÷ 150 ≈ 0.36 minutes, displayed as "22 sec". The arithmetic is linear, so the same paragraph repeated 20 times — 1,080 words — is 1,080 ÷ 238 ≈ 4.54 minutes, displayed as "4 min 32 sec", and speaks in "7 min 12 sec", whatever its content: the estimate knows nothing about difficulty, familiarity, or pauses, only the word count. The duration formatter rounds to the nearest second and shows minutes and seconds only when each is non-zero; anything that rounds below its smallest displayed span shows as "under 5 sec" (the vetted paragraph's reading time), and empty text shows as "0 sec".

Word finder

The word finder answers a different question from every other tool: not how much text there is, but which dictionary words a rack of letters can spell. Its engine is local to this site, like the case converter, and it is deliberately dictionary-agnostic — the word list is passed in as an argument, so the matching logic is tested against tiny lists and the browser loads the real one. The list this site ships is ENABLE, the Enhanced North American Benchmark Lexicon, a public-domain list of 172,820 lowercase entries, retrieved on 2026-07-18 and committed with its exact entry count pinned by a test. Its age is stated rather than hidden: ENABLE predates the 2006 tournament additions, so well-known two-letter words such as "qi" and "za" are not in it, and the finder will not report them.

A rack is parsed before anything is searched. Letters are case-insensitive a–z, spaces are ignored, and "?" marks a blank; the rack must hold between 2 and 20 tiles including blanks, with at most 2 blanks. So "Tea Pot" normalizes to "aeoptt" — 6 tiles, 0 blanks — and "teapot?" to "aeoptt?". Anything else is refused with a targeted message rather than silently cleaned: "tea4" returns "Digits are not letters — enter letters a–z only (use ? for a blank).", "t" returns "Enter at least 2 letters.", and "tea???" returns "At most 2 blanks (?) are allowed.".

Matching is letter-multiset containment. The rack becomes a tally of how many copies of each letter it holds; each candidate word becomes the same kind of tally; and a word is makeable when, for every letter, it needs no more copies than the rack supplies. Blanks relax that rule by exactly one copy each: sum the shortfall across all letters, and the word matches if that total deficit is at most the number of blanks. Candidates are filtered by length first — never shorter than the minimum length, which defaults to 2, and never longer than the rack — because that discards most of the list before any tally is built.

A worked example against an illustrative list of 22 words written for this page — not ENABLE, which is never loaded at build time and about which this example claims nothing: a, ape, apt, at, ate, eat, opt, otter, pat, patent, peat, poet, pot, potato, tap, tape, tea, teapot, to, toe, top, tot. Searching "Tea Pot" finds 18 of them, grouped longest first and alphabetically within each length:

• 6 letters — teapot
• 4 letters — peat, poet, tape
• 3 letters — ape, apt, ate, eat, opt, pat, pot, tap, tea, toe, top, tot
• 2 letters — at, to

Absent are a, otter, patent, potato: "a" falls under the default minimum length, and each of the others needs one more copy of a letter than the rack holds — "otter" needs one copy of r where the rack holds none; "patent" needs one copy of n where the rack holds none; "potato" needs two copies of o where the rack holds one. Add one blank, "teapot?", and patent, potato, otter appear, taking the total to 21; the blank absorbs a deficit of one, and no word on this list needs more. Results are ordered deterministically — groups by word length descending, alphabetical within a group — and capped at 5,000 words. When a rack matches more than that, the per-length counts and the total stay exact and only the returned lists are trimmed, with the truncation flagged; nothing was trimmed here.

Input limits and failure behavior

The engine accepts up to two million characters per analysis and reports an explicit message, never a silent wrong answer, when input exceeds that. Empty text returns zeros across the board; whitespace-only text returns zero words, sentences, paragraphs, and characters without spaces — its with-spaces count still reflects the whitespace itself. There is no sampling or approximation at any size — every count is computed over the full text on every keystroke.

Both behaviours are checkable. Analysing a text one character over the cap returns the message "Text longer than 2 million characters is not supported.", and the case converter applies the same cap with the same message. A text made only of spaces, a tab, and a line break returns 0 words, 0 sentences, 0 paragraphs, and 0 characters without spaces — though its with-spaces character count is 5, because whitespace is still made of characters. The word finder has its own limits, stated above, and its own messages.

Verification

Two properties are checkable by anyone. First, privacy: counting is local JavaScript on static pages, so your browser's network tab shows zero requests while you type, and a loaded page keeps working offline. Second, correctness: the engine is a set of pure functions pinned by an automated test suite covering hyphen and apostrophe joining, Unicode and emoji cases, the abbreviation over-count, paragraph edge cases, and the duration arithmetic. The same engine is shared byte-for-byte with our sister sites WordCounterPro.ai and WrdCntr.com, so a confirmed fix on any site reaches all three. Every worked-example figure on this page is itself produced by those functions when the site is built: change a rule and the figures here change with it, or the build fails. Suspected miscounts are welcome via the contact page — confirmed ones are fixed in the engine and locked in with a new test.

Counting happens locally in your browser — nothing you type is transmitted or stored. Counts are Unicode code points; platform-specific quirks are noted above. See the guides.