Does Your Word Counter Upload Your Text? A Guide to Private Text Analysis

A word counter looks like one of the simplest tools on the web. You paste in a draft, read a number, and leave.

But the text inside that box may be anything but simple. It could be an unpublished article, a client proposal, a job application, a legal draft, meeting notes, or the first version of a book. Before pasting that material into any website, there is a useful question to ask:

Does this tool need to upload my writing in order to analyze it?

Sometimes the answer is yes. A service may offer server-based optimization, document history, team collaboration, or AI feedback that cannot work without sending content elsewhere. Those features are not automatically improper, but they create a different privacy boundary. The user should be able to understand that boundary before submitting a draft.

We built the free MonkeyTactics Word & Character Counter around a narrower design: the text analysis runs in your browser. The draft does not need to be submitted to a MonkeyTactics analysis API.

This article explains what that statement means, what it does not mean, and how you can check it for yourself.

“Online” does not necessarily mean “uploaded”

A browser can do substantial work after a page has loaded. JavaScript can count words, update an interface, save preferences, draw charts, and generate files. WebAssembly can run compiled code inside the browser. Web Workers can move expensive computation away from the main interface thread.

That means an online utility can follow either of two broad designs:

1. Send the text to a remote server and return the result.
2. Download the application code, then process the text on the user’s device.

The interface may look identical in both cases. A large text box and a “Count” button do not reveal where the calculation happens.

Server processing may be necessary for some products. Accounts, synchronized history, shared workspaces, cloud-based language models, and centrally maintained document libraries all require network services of some kind. The privacy issue is not simply that a server exists. It is whether the product clearly explains what leaves the device, why it is sent, and how it is retained.

For a word counter, many useful measurements do not require that tradeoff.

What a text-analysis service could receive

If a tool sends editor content to a backend, that service can technically receive the complete submitted text. Depending on its design and policies, related systems might also process metadata such as the time of the request, IP address, browser information, account identity, or document identifier.

That does not prove the service stores drafts or uses them for another purpose. Privacy claims should not be built from guesses about products we have not inspected. It does mean the architecture creates possibilities that a purely local calculation does not.

Several common product features are signs that server processing or storage may be involved:

• A document remains available after you sign in from another device.
• Team members can edit or comment on the same draft.
• The service maintains a cloud-based optimization history.
• An AI assistant rewrites or evaluates passages using a hosted model.
• The page’s network activity includes requests containing the submitted text.

None of these features is inherently bad. They simply deserve a clear explanation—especially when the material is confidential or unpublished.

How the MonkeyTactics text analyzer works

The MonkeyTactics counter separates quick interface updates from heavier analysis.

As you type, a lightweight JavaScript path updates the core summary: words, characters, characters without spaces, lines, sentences, paragraphs, reading time, and speaking time. Modern browsers use locale-aware segmentation so languages that do not place spaces between every word can be handled more meaningfully than with a simple split-on-spaces rule. For very large documents, those summary updates wait until typing pauses instead of rescanning millions of characters after every keystroke.

The deeper analysis is performed by a Rust engine compiled to WebAssembly. It calculates data used for:

• keyword counts and density;
• unigram, bigram, and trigram frequency;
• readability measurements;
• sentence-rhythm visualization;
• paragraph-structure visualization; and
• keyword distribution across the draft.

WebAssembly is a portable compilation target that allows languages such as Rust to run alongside JavaScript in the browser. It is useful here because the analysis core can be typed, tested, and reused while remaining on the user’s device.

WebAssembly is not what makes the tool private. Wasm code can participate in network requests through JavaScript just as other web applications can. The privacy property comes from the application design: the analysis path does not submit the editor text to a remote calculation endpoint.

Why the analyzer uses a Web Worker

Analyzing a short paragraph is easy. Recounting keywords, phrases, sentences, and paragraphs throughout a book-length document is much more demanding—especially when the calculation repeats while someone is editing.

The analyzer normally runs its Rust/WASM workload engine inside a Web Worker. Web Workers run scripts in a background thread, separate from the page’s main interface context. The page sends the current text to the local worker, and the worker returns structured results to the page.

“Send” in that sentence means communication within the browser. It is not an upload to a MonkeyTactics server.

Keeping the heavier work away from the main thread helps the editor, controls, and tabs remain responsive. The application also delays analysis briefly while typing, reschedules work that has not started when the text changes, and ignores results produced for an older version of the draft.

The analyzer also has a complete JavaScript fallback with the same result structure as the Rust/WASM engine. If WebAssembly cannot initialize, the Worker runs the JavaScript analyzer so keyword density, phrases, readability data, and structure charts remain available. During local development, an explicit debug mode can run both implementations against the same text, compare their results, and report timing differences. Normal use runs only WASM and avoids paying for the same analysis twice.

That distinction is important. Resilience comes from an independently testable fallback, not from a vague promise that every feature will work under every browser condition.

What changes for very large documents

Moving calculation into a Worker prevents heavy analysis from directly blocking the editor, but it does not make every other browser cost disappear. Copying a large string to a Worker, counting Unicode text, laying out a multi-million-character text area, building thousands of table rows, and drawing tens of thousands of chart bars can still consume time and memory.

The counter therefore changes its scheduling and rendering strategy as documents grow:

• Summary calculation and full analysis use longer adaptive delays, and both restart when the user resumes typing.
• Autosave waits for an idle period so an obsolete draft is not written while edits continue.
• Density, Phrases, Readability, Sentence Rhythm, and Paragraph Structure are rendered only when opened.
• An expensive tab is cached for the current analysis revision, so returning to it does not rebuild the same rows or bars.
• The text editor remains laid out—but invisible and inert—behind Density and Phrases. This avoids reconstructing millions of characters when the user returns to Text.
• Sentence and paragraph ranges are prepared outside the immediate click path. Chart selections use delayed repositioning so rapid clicks do not start competing editor scroll operations.
• Large-document paragraph navigation estimates wrapped visual lines from the editor’s actual font and width rather than assuming that character position maps directly to scroll position.

During development, we used documents from roughly 220,000 words to more than 1.3 million words as stress tests. The largest test contained about 7.4 million characters, 65,000 sentences, and 17,000 paragraphs. That is well beyond a typical article or manuscript. It is not a promise that every device will handle documents of that size equally well, but it is useful for exposing blocking work, excessive rebuilding, stale results, and memory that is not reclaimed after an edit.

Temporary memory growth during a large edit is expected: the browser may briefly hold the old text, the new text, a Worker message, analysis arrays, chart data, and an autosave snapshot at the same time. The healthy pattern is for memory to fall again after obsolete work completes and garbage collection runs. A resting memory level that grows after every edit and never returns would warrant investigation.

What optional autosave stores

Losing a long draft to an accidental refresh is frustrating, so the editor offers optional autosave. When enabled, the current draft and relevant editor settings are saved in browser-managed storage. They are not placed in a MonkeyTactics user account because the tool does not require one.

Draft content is stored asynchronously in IndexedDB, which is better suited to large text than synchronous localStorage. Small preferences can still use local storage, and drafts saved by the earlier implementation are migrated when possible. In practical terms, autosave consumes storage on the device—not MonkeyTactics server storage or active memory that remains permanently occupied.

Autosave uses an idle delay and cancels the pending timer when typing resumes. The interface changes the Autosave label to Saving… during the delay and write, then changes it back without inserting a status row that would resize the editor. IndexedDB removes the previous one-megabyte application limit, although the browser and device can still enforce their own storage quotas.

Local browser storage still deserves care:

• Someone using the same browser profile may be able to reopen the draft.
• Browser extensions or malicious code with suitable access can weaken the local trust boundary.
• Clearing site data removes the saved copy.
• Private-browsing modes generally remove site storage when the private session ends.
• Autosave is a recovery convenience, not a versioned backup system.

You can disable Autosave in Editor settings. Starting a new draft also provides a way to clear the saved editor content.

How to check whether a word counter uploads text

You do not have to rely entirely on a site’s marketing language. Modern browsers include tools that show network activity.

Here is a practical check in Chrome or another Chromium-based browser:

1. Open the word counter, but do not paste sensitive material. Use a unique test sentence instead.
2. Open Developer Tools and select Network.
3. Clear the existing request list so page-loading traffic does not obscure the test.
4. Paste the test sentence into the editor and change it several times.
5. Look for new Fetch or XHR requests.
6. Open any suspicious request and inspect its URL, headers, and payload.
7. Search the recorded request data for a distinctive phrase from your test sentence.

Chrome’s documentation explains how to inspect network activity and request payloads. The absence of a matching request during one test is not a mathematical proof of every future version, but it gives you evidence about the page currently running in your browser.

You can perform a second test by loading the tool, switching the browser’s network condition to Offline, and then editing the sample. A locally implemented counter should continue calculating after its required application files have already loaded. Features that intentionally depend on outside services may not.

Remember that initial requests for HTML, JavaScript, CSS, fonts, and the WebAssembly module are normal. The question is not whether the website uses the network at all. The question is whether your editor content appears in a request.

What local processing does not protect against

Local-only analysis reduces one specific risk: transmitting a draft to a text-analysis backend. It does not make the browser or device invulnerable.

A compromised computer can expose locally processed text. An untrusted browser extension may be able to inspect pages. Clipboard managers can retain copied passages. Screen-sharing, screenshots, synced browser profiles, backups, and other software may create additional copies. A person with access to the same unlocked profile may also see an autosaved draft.

The right claim is therefore not “local processing eliminates privacy risk.” It is more precise:

Local processing removes the need to send the draft to a MonkeyTactics analysis server.

That is a meaningful reduction in exposure, but it remains one layer in a larger privacy model.

When you should avoid any online editor

Even a local-processing web tool may be inappropriate for material governed by strict organizational, contractual, legal, or regulatory rules. If a policy prohibits pasting content into a browser-based tool, local execution does not override that policy.

For highly sensitive material, consider an approved offline application on a managed device. Ask whether the document is subject to client confidentiality, legal privilege, health-data restrictions, employment rules, export controls, or an internal data-classification policy. When the answer is unclear, use harmless sample text until the responsible person confirms the permitted workflow.

Privacy-friendly design should help users make informed decisions, not encourage them to ignore their obligations.

A useful word counter should explain its boundaries

We wanted the MonkeyTactics counter to be capable enough for serious editing without turning every draft into a server-side data flow. It can analyze large documents, count multilingual text, compare keyword distribution, measure phrase frequency, estimate readability, set length targets, and navigate sentence or paragraph structure—all within the browser.

Its boundaries are equally important:

• The tool is an analyzer, not an AI writing service.
• Readability scores are estimates, not judgments of quality.
• Keyword density is a diagnostic signal, not an SEO target.
• Browser autosave is optional local recovery, not cloud backup.
• PDF import extracts selectable text and ignores images.
• Local processing reduces server exposure but cannot secure a compromised device.

These details make the privacy statement smaller than “your data is always safe,” but much more useful.

Try it—and verify it

Use the MonkeyTactics Word & Character Counter with sample text first. Watch the live counts, open the Density and Phrases tabs, adjust reading and speaking speeds, and inspect the sentence and paragraph charts.

Then repeat the Network-panel test above. The source code is also available on GitHub for anyone who wants to inspect the worker, WebAssembly wrapper, autosave behavior, or analysis interface more closely.

The goal is not to ask for blind trust. It is to make a useful privacy property understandable and testable:

Your writing can be counted and analyzed without becoming an upload to our text-analysis server.