Word Counting & Full-Text Search: From Essays to Scripture

“How many words is this?” sounds like a question with an obvious answer — until two serious tools disagree by 3% on the same essay. Counting words turns out to be a language-technology problem in miniature: tokenization, Unicode, and policy choices all hide in the seam. Those same seams widen into full-text search when the text grows from one essay to an entire Bible — about 790,000 words that must be searchable in milliseconds. This guide is the engineering behind both wordcount.gotool.app and bible.gotool.app.

What is a word, exactly?

Naively, a word is “text between spaces”. Reality pushes back immediately:

• Hyphens and apostrophes. Is “state-of-the-art” one word or four? “Don’t” — one or two? Counters must declare a policy, not a truth. (wordcount.gotool.app follows common editorial practice: one word per hyphenated compound, one per apostrophe form.)
• Unicode whoppers. Japanese and Chinese are written largely without spaces — a whole sentence can be one whitespace-delimited run. Proper tokenizers implement UAX #29 text segmentation, the Unicode standard's word-breaking algorithm, with per-language refinements.
• Emoji and combining marks. A family emoji with zero-width joiners is one grapheme cluster but many code points; “é” can be one character or two (e + combining accent). Count bytes, code points, grapheme clusters or words — four different numbers.

This is why two counters disagree. Both are right about their own definition and wrong to imply the definition is obvious.

What the metrics are actually for

Writers do not count words for fun; the numbers gate real constraints:

• Commissioned work. Per-word billing needs a count both sides can reproduce — worth agreeing on the tool in the contract.
• Hard limits. Abstracts with 250-word caps, applications with character ceilings, meta descriptions that truncate past ~160 characters.
• Reading time. The familiar “x min read” is words ÷ pace — 200–250 wpm for prose, slower for technical material. Honest sites state the pace; wordcount.gotool.app shows its arithmetic.

A good counter therefore reports the whole panel — words, characters (with and without spaces), sentences, paragraphs, reading time — computed live as you type, with the definitions documented. wordcount.gotool.app does exactly that, in the tab, for text you may not want anywhere else: cover letters, manuscript drafts, therapy journals, exam answers.

From counting to searching: the inverted index

Now scale the problem up. Searching 31,000 Bible verses by scanning every word of every verse on every keystroke is hopeless. Search engines solved this a century ago with the inverted index — the same idea that powers every search box you have ever used:

1. Tokenize and normalize. Split into terms, fold case, strip diacritics, optionally reduce words to stems (“mercy”, “mercies” → “merci”).
2. Invert the mapping. Instead of document → words, store word → postings list: the sorted list of every verse reference containing the term.
3. Intersect postings. A two-word query is a list intersection — milliseconds even for common words.
4. Rank the hits. Classic scoring (TF-IDF, or its sharper descendant BM25) rewards rare terms and terms that dominate their verse, so “grace” ranks its densest matches first.

The entire index for the King James Bible compresses into a few megabytes of postings — small enough to ship to the browser and hold in memory.

Scripture search has its own conventions

Biblical text rewards tooling that understands its shape. bible.gotool.app builds the conventions in:

• Reference parsing. “John 3:16”, “Jn 3:16” and “3jn16” should all land in the same place — a small parser with book aliases handles the shorthand readers actually type.
• Verse-level precision. The postings unit is the verse, so a phrase query (“still small voice”) matches exact spans and every result is citable.
• Cross-references and chapter context. Search that dumps you at verse 14 with no chapter in view is a lookup, not study. The reader keeps the full chapter around the hit.
• Instant-as-you-type response. Because the index is local, results can recompute per keystroke with no round-trip and no rate limit.

Why local text processing matters

Text is the most revealing data we have. A search history through Scripture can expose doubts, grief and plans; a word counter may be holding your unpublished novel or your legal statement. On bible.gotool.app and wordcount.gotool.app, the tokenizer, the index and your query all execute inside the tab — nothing to leak, nothing to subpoena, nothing to breach.

The takeaway

Counting words is tokenization policy with a user interface; searching Scripture is counting words with an inverted index and a century of ranking theory behind it. Both are pure computation — which is exactly why they belong in your browser. Define the count you mean, search with a real index, and keep the words where they started.