Your Grammar Checker Reads Everything You Type: A Privacy Checklist

Run any cloud grammar checker and here is what it receives: the full text of whatever you let it check — usually the entire document, not just the sentence with the mistake — plus your account identity, device and usage metadata, and, for browser extensions, the text of nearly every editable field on nearly every site where the extension is active. That text is processed on the company’s servers, where, depending on the terms you clicked through, it may be logged, retained for months or years, opened by employees during debugging, or used to improve models. Before you trust a checker with anything sensitive, you need answers to five questions: what exactly is transmitted, how long it is kept, whether it trains models, who inside the company can read it, and what account deletion actually deletes.

For genuinely sensitive documents — visa letters, client work under NDA, unpublished research — the safe workflow is short: check a scrubbed copy with names, numbers, and identifiers replaced by placeholders (grammar mistakes survive redaction just fine); fix structure and readability before the full text ever leaves your machine; and reserve whole-document cloud checking for tools whose retention and training terms you have actually read. The rest of this post turns those two paragraphs into a checklist you can act on.

What a cloud grammar checker actually receives

There is no way around the core mechanic: to check your grammar, the tool has to read your text. The local spell-checkers of the 2000s did this on your machine. Modern checkers do it on a server, because the models that catch article errors and unnatural phrasing are too large to run in a browser tab. “Cloud grammar checker” is, functionally, a service you paste your documents into.

What that means in practice depends on the surface you use:

The browser extension row deserves a second look. An extension with permission to read page content does not distinguish between your blog draft and the message you are typing to your lawyer. Unless the vendor scopes it carefully — or you disable it per site — “checks my writing” quietly becomes “reads most of what I type at work.” I write English as a second language, Ukrainian first, and I still draft tricky paragraphs in Ukrainian before rewriting them in English. Those half-formed bilingual drafts sit in exactly the same text fields an extension reads. (If your drafts work the same way, you may recognize the symptoms described in why your English sounds translated.)

None of this requires malice or a bug. It is the normal operation of the product.

Why “LanguageTool security vulnerability” became a rising search

I watch the search queries that bring people to diglot.ai, and one has been climbing steadily: languagetool security vulnerability. I am not going to claim knowledge of any specific flaw, and this post is not about one. The interesting part is who is searching. LanguageTool’s core is open source and can be self-hosted, which historically made it the choice of privacy-conscious writers. When exactly that audience starts googling security questions, it signals something bigger than any one product: people are realizing that a grammar checker is not a small utility. It is a service with standing access to their most candid, least polished writing.

The realistic threat model has three layers, ordered by likelihood:

1. Policy (most common). Your text is retained, logged, or used for model improvement in ways you technically consented to but never read.
2. Scope (very common). An extension or keyboard reads far more than you intended — not a breach, just breadth.
3. Breach (rarest, most discussed). A vulnerability exposes stored text. Note the dependency: the less a vendor retains, the less any breach can expose. That is why the retention questions below matter more than any individual security headline.

The privacy checklist: seven questions to ask any grammar checker

Ask these before pasting anything you would not forward to a stranger. A serious vendor answers all seven in its privacy policy or data processing agreement. If you cannot find an answer, treat the silence as the answer.

1. What exactly is transmitted? The whole document on every pause in typing? The active paragraph? Some tools resend full text constantly; others send segments or diffs. Fewer bytes leaving your machine means less to retain, log, or leak.
2. How long is my text retained? “Processed transiently and discarded” and “stored as documents in your account” are radically different postures that read almost identically in marketing copy. Look for concrete retention windows with numbers in them.
3. Is my text used to train models? Check the default, not just the existence of a toggle. Opt-out-by-default means every sensitive paragraph you checked before finding the setting is already in the pipeline. Business tiers often exclude training while free tiers do not — verify for the tier you actually use.
4. Who inside the company can read it? Debugging logs, human review of AI output, and support access are legitimate operations — and all of them can put employees in front of your text. A careful vendor describes its access controls; a vague one says “trusted personnel.”
5. Which subprocessors see it? Most modern checkers call external AI vendors under the hood. Your text’s real footprint is the union of every subprocessor’s policies, and the list should be public.
6. What does account deletion actually delete? Deleting your login is not deleting your documents, and neither necessarily purges backups or copies held by subprocessors. Look for stated deletion timelines that cover downstream systems.
7. Can I scope it down? Per-site disable in the extension, an off switch for specific documents, a no-training setting, or a self-hosted option. A tool that offers scoped modes is a tool whose maker has thought about this problem at all.

How to check sensitive documents safely

The working principle: separate the text that needs grammar help from the details that make it sensitive. They are almost never the same words.

Visa and immigration letters

A visa support letter is a privacy worst case: full legal name, passport number, date of birth, addresses, travel history, sometimes the sponsor’s finances. But the grammar of “NAME has been employed at COMPANY since DATE” is identical to the grammar of the real sentence. Replace every identifier with a placeholder, run the check, then restore the details by hand. Ten minutes of redaction, and the facts that matter never leave your machine. For the structural pass — is the letter clear enough for a busy visa officer skimming it — run the scrubbed copy through a readability checker before you polish the grammar. In my experience, structure problems sink these letters more often than a missing article does.

Client work under NDA

Read your NDA before you read the checker’s privacy policy. Many confidentiality clauses prohibit disclosing client material to third parties — and a grammar checker’s server is a third party. Sending a client’s unreleased product spec through a consumer-tier checker can be a contract violation even if the vendor behaves perfectly. Your options, in ascending order of effort: check only your own framing text and keep the client’s material out; use a business tier with a signed DPA and explicit no-training terms; or get the client’s tooling policy in writing. Freelancers consistently underestimate how often a client will simply say yes to a named tool when asked directly.

Unpublished research

The risk for researchers is rarely a dramatic leak — it is quiet absorption. Text retained for “service improvement” can end up influencing models, and the novel phrasing in an unpublished manuscript is exactly the kind of distinctive text worth being careful with. A practical split: your methods and introduction sections are usually low-risk to check, while results, data tables, and the paragraph stating your core contribution deserve either a no-training tool or a redacted pass. Having built the server side of a grammar tool myself, I can tell you the version of your text a vendor holds is the rawest one you ever wrote. Treat drafts with more care than finals, not less.

What to demand from any vendor — including mine

Diglot is a cloud tool, so every question above applies to us too, and I would rather you ask them than assume. The honest baseline for any modern checker, ours included: your text is processed on servers, subprocessors are involved, and the real difference between vendors is what happens after — retention windows, training defaults, access controls, and how plainly those answers are written down. A vendor that treats the seven questions as unreasonable is telling you something useful.

If you write in English as a second language, you probably lean on a checker harder than a native speaker does — more of your text passes through it, at rougher stages, more often. That is exactly why this checklist matters more for us, not less. If you want an AI writing assistant built by someone who sees this pipe from both ends — as an ESL writer whose own drafts go through it, and as the person who watches what arrives on the server — that is what I am building at Diglot. Bring the checklist. We will answer it.