ToolSura
    ToolSura
    HomeTools
    Blog
    ToolSuraPrivacy-First Tools

    Free utilities that run in your browser. No trackers, no accounts, no uploads.

    All Systems Operational

    Product

    • Free Online Tools
    • Contact
    • FAQs
    • Feedback
    • About

    Legal

    • Privacy Policy
    • Cookie Policy
    • Terms & Conditions
    • Disclaimer

    Resources

    • Blog
    • Brand
    • Help

    Social Links

    • Bluesky
    • Mastodon
    • X
    • Product Hunt
    • GitHub
    • LinkedIn
    • DEV.to
    • YouTube

    © 2026 ToolSura. Free tools that run in your browser.

    Remote-First / Based in India

    Technical Manifesto

    Private • Client-Side • No Uploads

    ToolSura on Nick Launches
    Browser-Native
    Privacy-First
    Skip to main content
    Toolsura
    word-counter
    H
    Harriet Cole

    Choosing a word counter by testing it, not by its feature list

    September 2, 2026 · 8 min read

    Counters disagree for four fixable reasons. Learn to test tokenization, CJK handling, privacy and readability formulas on any word counter.

    How to Test Any Word Counter, Including WordCounter.net

    Two counters can disagree on the same paragraph, and both can be defensible. The gap is rarely effort; it is tokenization, the rules a tool uses to decide where one word ends and the next begins. Counters also carry inherited folklore. A meta-analysis of 190 studies across 18,573 participants traced the popular "300 words per minute" reading figure back to a 1978 study of only 10 skilled readers (Brysbaert, 2019). This guide is a framework for testing any counter rather than trusting its feature list.

    Key Takeaways

    • The clearest accuracy signal is whether a counter explains its tokenization rules. UAX #29 states that "some languages do not use spaces at all" (Unicode, UAX #29).
    • "don't" is one word in English, while "l'objectif" is two under French tailoring. The same string can have two correct answers.
    • Privacy is mechanically testable: open DevTools, watch the Network tab, and any fetch carrying your text is a round trip (MDN Fetch API).
    • A UAX #29 segmenter is an algorithm, not a model. Sending text to a language model is a different privacy decision entirely.

    What Is a Word Counter, Really?

    A word counter is a segmenter with a text box. Underneath, it applies a documented standard, the Unicode text segmentation algorithm known as UAX #29, to draw boundaries between words. The standard is blunt about why naive splitting fails: "Word boundaries are not restricted to whitespace and punctuation. Indeed, some languages do not use spaces at all" (Unicode, UAX #29). So a credible counter is really an implementation of a published rule set, and the most trustworthy ones tell you which rule set they follow.

    How do you test a counter's counting rules?

    You test it with known strings whose correct answers are already published. The clearest test string is the apostrophe. Under the default UAX #29 rules, "don't" is one word, because the apostrophe sits between letters and those rules keep them together. But the standard also defines a French and Italian tailoring that breaks at apostrophes, which makes "l'objectif" two words. The same input has two correct answers depending on locale, and a counter that cannot say which it implements is guessing. Try three more strings. "well-known" is one word, because the hyphen is excluded from the default definition. A phrase broken by an em dash is two words, because the em dash forces a break. And "3.14" is two words, because the decimal point splits it. WordCount.com is one worked example that publishes these rules in plain language (WordCount.com). Whatever counter you are testing, paste those strings first.

    A documentation gap is not a quality judgment

    Not every counter publishes its method. wordcounter.net, for example, presents feature headings such as its activity tracker and flow score without a documented counting method or a named language list (wordcounter.net). That is an observation about documentation, not a verdict on accuracy, and it is exactly the gap this framework fills. When a tool does not tell you its rules, you supply the test yourself. Run the three strings above and you will know more about that counter than its marketing copy tells you.

    Counting Chinese, Japanese, and Thai without spaces

    For Chinese, Japanese, and Thai, a counter that splits on whitespace collapses. A whole Chinese paragraph becomes one giant "word." The fix is locale-aware segmentation, and here is the honest limit. UAX #29 states that "Reliable word detection for Thai, Lao, Chinese, or Japanese requires the use of dictionary lookup or other mechanisms" (Unicode, UAX #29). When no dictionary is available, the standard falls back to rule WB999, which breaks everywhere around ideographs. Browsers expose this through the Intl.Segmenter API (MDN), specified in ECMA-402 (ECMA-402).

    Intl.Segmenter does not fully solve Thai

    This is where counters overclaim. Intl.Segmenter implements the UAX #29 default rules. Scripts like Thai and Khmer need dictionary-based tailoring, and implementations vary in how completely they apply it. So treat a "supports Thai" claim as something you test with real Thai text, not something you accept on faith. Check whether a Chinese paragraph produces a sensible per-sentence count, and whether Thai breaks into words rather than returning one number.

    Does a word counter upload your text?

    You can answer this without trusting any privacy policy. The Fetch API is what browsers use to request resources "including across the network" (MDN Fetch API). So the test is mechanical. Open your browser's DevTools, switch to the Network tab, paste a distinctive phrase into the counter, and watch. If any fetch, XHR, or beacon request carries your text, the text left your device. If the tab stays silent, the counting happened locally. Local execution is usually powered by Web Workers, which run "in a background thread separate from the main execution thread" (MDN Web Workers), and often WebAssembly, a portable low-level format designed for fast, memory-safe execution (W3C WebAssembly). The point is not that a tool is branded "private." The point is that you verified it.

    Is an AI feature the same as ML-based counting?

    No, and the distinction is a privacy decision, not a technical flourish. Counting words via UAX #29 is deterministic pattern matching. It is an algorithm, and no text needs to leave the page to run it. A language model, by contrast, must receive your text to produce output, because inference happens where the weights live. So a model-based feature such as a "rewrite this shorter" button necessarily routes your draft somewhere. That means "uses AI" and "uses machine learning for counting" are two different claims, and only the second is compatible with local-only processing. If a counter conflates them, ask which specific feature actually calls a model. The same logic governs local models versus API models: once a request leaves the device, local processing stops being local.

    Is a readability score a grade certificate?

    No. A readability score is one weighted formula, and it is worth reading the weights. Flesch Reading Ease is 206.835 minus 1.015 times (words divided by sentences) minus 84.6 times (syllables divided by words) (Flesch, 1948). Flesch-Kincaid Grade Level is 0.39 times sentence length plus 11.8 times syllables per word, minus 15.59. Gunning Fog is 0.4 times the sum of sentence length and 100 times the share of words with three or more syllables (Gunning Fog). Grade level has no upper bound, Reading Ease has no lower bound, and the two are not convertible. Read a score as a trend across your own drafts, not a certificate of who can read your work.

    Reading time deserves the same skepticism

    Reading time is a guess layered on top of the count, so check the rate. Adult silent reading of non-fiction runs about 238 words per minute, and fiction about 260 (Brysbaert, 2019). For speaking time, be careful with the folk figure. Measured speaking rates vary a lot by context, and recent conversational speech corpora put everyday rates well above 150 words per minute, so a counter that hardcodes 150 is using a stale constant. For how rate context changes what you build, see browser-native text to speech.

    How do you cross-check two counters and reconcile the totals?

    When two counters disagree, check four causes in frequency order. First, tokenization: hyphens, apostrophes, em dashes, and decimals are the usual culprits. Second, locale: a French tailoring splits "l'objectif." Third, what counts at all, such as whether emoji or headings enter the total. Fourth, reading-time and grade-level rates, which are estimates stacked on top of the count. Start by finding the first string where the two totals diverge, because that single difference usually identifies the rule at work. Why word count tools give different totals covers these mechanics in depth, and word count vs character count explains the other two figures every counter reports.

    A faster method is to test a handful of probe strings, each isolating one rule, and compare the outputs side by side. Paste well-known and watch whether the total moves by one or two. Paste don't and see whether the apostrophe is absorbed. Paste a Japanese sentence with no spaces and check whether the count is one or roughly the number of words a reader would say. Paste 3.14 and e.g. to see how decimals and abbreviations land. Five probes will tell you which standard a counter is following far more reliably than reading its feature list, and they take under a minute.

    Once you have identified the rule, reconcile by hand and you can trust the number for whatever limit actually matters. If a submission is graded by an application, count in the tool that application uses. If a school or publisher supplies a guide, follow that guide rather than any counter's default.

    Word count targets worth knowing

    A correct count only matters if the target is right. Novelists usually plan against 80,000 to 100,000 words, and academic work against your department's cap. The question "how many words in a paragraph" comes up more than any other, which is why we have a dedicated explainer, and the adjacent "how many sentences in a paragraph" question matters just as much for pacing. If you only need a quick total, how to check word count covers the counters already built into Docs and Word. For the privacy-first habit of keeping text on your own machine, privacy-first online tool alternatives is the pattern this method comes from.

    How do you actually choose?

    The framework collapses to three checks you can run in a minute. Paste the apostrophe, hyphen, and em-dash strings and see whether the tool's answers match a published rule. Open the Network tab and see whether your text ever leaves the device. Read the readability formula and decide whether you want a formula or a feeling. A counter that passes all three has told you how it works, and that is the only credential that matters. This is the same discipline we apply across privacy-first tools: verify the claim, then use it. The ToolSura word counter is offered as a worked example you can run these same tests against, not as a verdict. Take the framework, apply it to any counter, and keep the one that can show its work.

    Related Tools & Further Reading

    • Try it on your own text: the ToolSura word counter runs in-browser with no server round trip, and reports words, characters with and without spaces, sentences, paragraphs, readability grades, and keyword density.
    • Counting mechanics: why word count tools give different totals breaks down tokenization rules, and word count vs character count covers the two character figures.
    • Built-in counts: how to check word count reviews the counters already in Docs and Word.
    • Privacy patterns: local models versus API models and privacy-first online tool alternatives.
    • Paragraph math: how many words in a paragraph and how many sentences in a paragraph.
    Harriet Cole

    Written by

    Harriet Cole

    My whole subject is that a word count is not one number, and the definition used changes it by a large enough margin to matter when a limit applies. Splitting on whitespace counts space-separated tokens, which treats a hyphenated word as one and a number with a decimal point as one. Splitting on a word-boundary regular expression splits both, and splits contractions in ways nobody expects. Counting characters is simpler and more ambiguous still, since whether spaces count changes the total by a few percent and whether a character means a code point or a byte depends on the encoding.

    Sentence counting is the least reliable of the set. Splitting on a period followed by a capital breaks on abbreviations and on decimal numbers, so 3.14 and e.g. each produce a sentence boundary that does not exist. Any figure produced this way carries an error rate worth knowing about.

    Paragraph counting needs a rule about blank lines, because some formats separate paragraphs with a blank line and others do not. Reading time is the most quoted and least examined. It comes from a words-per-minute figure, that figure is a population average, and it assumes continuous focused reading.

    Technical text read carefully is slower, and skimming is faster. I state the rate on every page rather than presenting the minutes as a measurement. I also cover what the count is used for, because a limit is enforced somewhere and knowing whether the limit counts markup changes the answer substantially. Where a limit applies, I would rather the tool counted with the same definition the rule was written against than quietly applying its own.

    Share

    Frequently Asked Questions

    PreviousBrowser Tools vs Desktop Software: Which to Use?NextBase64 Encoding Explained: What It Is & How It Works

    Comments

    Leave a Review

    Rate this tool
    Overall Rating
    Spam Protection Active