Every cloud grammar checker makes the same quiet request before it helps you: paste the draft. For a note to a teammate, that request costs nothing. For a contract summary under NDA, an unreleased launch announcement, or a client report full of real names and figures, it costs more than most people admit — Grammarly, and clones like Steer, process your text on their servers, because that is how the business works. The free grammar and style checker at Practical Web Tools takes the other route: the entire check runs in your browser tab, start to finish.
The tool underlines each issue and offers a one-click fix, generates a readability report, and works in two tiers: a local ML model pass plus rule checks for passive voice, adverb overuse, and long sentences. In testing on a deliberately flawed sample, it surfaced 30 distinct issues — enough red underlines that the sample's problems stopped being subtle. This is a checker you can point at a draft you are not allowed to paste anywhere else.
Try Grammar & Style Checker — free, no sign-up.
And if your next stop is an AI chatbot rather than a human reader, pair the checker with the PII redactor: scrub the identifying details first, fix the grammar second, paste last. The rest of this article covers how the two-tier check works, how to read the readability report, and that redact-check-paste workflow in order.
When "don't paste this" is the whole use case
Cloud checkers are not being sneaky; server-side processing is the product. The features that justify a subscription — team style guides, tone analysis, weekly writing reports — all require your sentences to reach their infrastructure, and clones like Steer follow the same architecture. For a blog post or a newsletter draft, that is a reasonable trade. It is the wrong trade for text that carries obligations:
- Drafts under NDA, where sending text to a third party is a problem no matter how secure the pipe is
- Client work containing real names, account numbers, and unpublished figures
- Unreleased financial, legal, or medical documents
- Personal writing you simply do not want mirrored onto servers you do not control
If you want the full anatomy of what happens to files pasted into AI services, we covered that in a separate deep dive; the short version is that once text leaves your device, you are relying on someone else's retention policy. A checker that runs locally ends the question before it starts: no upload, no sign-up — nothing you type or drop leaves your device.
Two tiers: rules for the mechanical, a model for the sneaky
Most writing problems are not exotic. They are passive constructions, hedges stacked three deep, and sentences that grew a second clause nobody asked for. The checker's rule tier handles exactly those, deterministically: passive voice, adverb overuse, and long sentences each get pattern-based detection. Rules do not "understand" your paragraph, which is their strength — a rule never gets tired, never skips a sentence, and never flags the same construction only when it feels like it.
The second tier is a local ML model pass that reads sentence structure and catches what patterns cannot: agreement errors. The classic case is a subject and verb separated by a long noun phrase — "The list of items from yesterday's review are still open." The plural noun right before the verb ("items") pulls your eye toward "are," but the head of the subject is "list," and the correct verb is "is." A regex struggles with that; a model that parses the sentence does not. Each issue it finds gets the same treatment: an underline and a one-click fix.
| Tier | What it catches | Example it nails | Why it is reliable |
|---|---|---|---|
| Rule: passive voice | was/were plus past participle | "The results were confirmed by no one" | deterministic pattern match |
| Rule: adverb overuse | filler adverb density | "the report was very clearly quite wrong" | counting, not judgment |
| Rule: long sentences | sentence length in words | a 58-word sentence with four clauses | a measured threshold |
| Model pass | agreement and context errors | "the list of items are long" | reads structure, not patterns |
In practice the two tiers argue with each other usefully. The rules give you the mechanical sweep — every passive, every hedge, every runaway sentence — while the model pass handles the errors that make a reader pause without knowing why. On the flawed sample mentioned above, that combination produced the 30 flagged issues, each with a suggested fix one click away.
Reading the readability report
Alongside the underlines, the checker produces a readability report built on the Flesch Reading Ease scale. The formula is public and worth knowing in outline: 206.835, minus 1.015 times the average words per sentence, minus 84.6 times the average syllables per word. Two inputs, both of which you control. Long sentences drag the score down; long words drag it down faster.
| Score | Reads like | Audience |
|---|---|---|
| 90–100 | very easy | 5th grade |
| 70–90 | easy | 6th–8th grade |
| 60–70 | plain English | 8th–9th grade |
| 50–60 | fairly difficult | 10th–12th grade |
| 30–50 | difficult | college |
| 0–30 | very difficult | graduate level |
The practical target for most working writing — emails, docs, blog posts, support articles — is 60 to 70. Below that range you are asking readers to work; far above it, text can start to feel clipped. Two honest caveats: the formula only sees syllables and sentence length, so jargon-heavy but well-written technical prose can score poorly; and scores are a trend line, not a verdict. The useful move is to check the score before and after a revision pass. Breaking two 40-word sentences in half usually moves the needle more than swapping any single word, and the report makes that visible.
The pre-LLM workflow: redact, check, then paste
A lot of the checking people used to do by hand now goes through an AI chatbot — tighten this, make it friendlier, cut it to 150 words. That is convenient and, for sensitive drafts, exactly backwards. If you redact after the model has seen the text, the data has already left. The order has to be redact, check, paste:
- Draft normally, in whatever editor you use.
- Run the draft through the PII redactor. Its regex and rule detection finds emails, phone numbers, SSNs, and card and IBAN numbers; an optional local named-entity pass looks for names that the patterns miss.
- Copy the scrubbed text into the grammar checker and work through the underlines.
- Paste the cleaned, redacted text into the chatbot, get your edit, and paste the result back if you want a final pass.
The step people skip is step 2, and it is the one that matters. A prompt like "polish this email to a client" routinely carries client emails, phone numbers, and invoice figures straight into someone else's logs. Redacting first costs a few seconds; the chatbot does not need real names to tighten your prose, and "the client" works as well as a name for editing purposes. The same discipline applies before sharing drafts with collaborators: strip the identifiers you do not need feedback on.
What the rules catch that large models miss
It is fair to ask why a tool bothers with rules at all when language models exist. Three reasons, all practical:
- Rules give you totals, not judgments. A model pass evaluates one sentence at a time. The passive-voice rule shows you the pattern across the whole draft — if every second sentence is "it was decided that," you have a style problem to fix at the source, not forty individual suggestions to accept.
- Filler adverbs are grammatical. "Very," "really," and "basically" break no grammar rule, so a model focused on errors has little reason to touch them. An overuse rule counts them and makes you defend each one. Cutting hedges is often the single fastest way to make prose feel sharper.
- Long sentences are not wrong. A 60-word sentence can be perfectly grammatical and still lose the reader. No error-class model flags it; a word-count rule measures it.
The flip side is honest to state: rules encode style opinions. Passive voice is the right choice when the actor is unknown or irrelevant — "the build was reverted at 14:02" is better than naming a scapegoat — and scientific writing leans on it for good reasons. Treat every rule flag as a question, not a correction you must accept.
Honest limitations
A local model is compact by design, and that has consequences. It catches common error classes reliably; it will not match a large cloud service that has been tuned on billions of edited sentences for every nuance. There is no independent benchmark comparing the two approaches, so the honest advice is to test both on a paragraph of your own writing and see which findings you actually agree with.
Second, the tool checks and suggests; it does not decide. The one-click fixes are good, and the two-tier design means mechanical issues are caught exhaustively, but final judgment on style stays with you. Third, the readability formula is a heuristic — useful as a trend line, misleading as a grade. And fourth, for high-stakes documents, no checker replaces a careful human read before the thing ships.
What local processing buys you is not better grammar checking in every dimension. It is the ability to run the check at all on drafts that were never eligible for the cloud — with the grammar checker open in a tab and the redactor one click away, the privacy question and the quality question stop being in tension.
Frequently Asked Questions
Does the grammar checker upload my text anywhere?
No. The check runs in your browser — no upload, no sign-up, nothing you type or drop leaves your device. That is the core difference from cloud checkers, and the reason it is usable on drafts you are contractually not allowed to share.
How does it compare to Grammarly for catching errors?
The architectures differ. Grammarly processes text server-side with large models; this tool combines a local ML model pass with deterministic rule checks — passive voice, adverb overuse, long sentences — and offers one-click fixes plus a readability report. In testing it flagged 30 issues on a deliberately flawed sample. For NDA-class drafts, the local tool is the only one of the two that is appropriate at all.
What does the readability score actually mean?
It is a Flesch Reading Ease score from 0 to 100, computed from average sentence length and average syllables per word. Around 60 to 70 is plain-English territory for a general audience; scores below 30 read at graduate level. Use it as a before/after trend line for revisions, not as a grade.
What should I remove before pasting text into an AI chatbot?
At minimum the categories the PII redactor detects: emails, phone numbers, SSNs, and card or IBAN numbers, plus names via its optional local named-entity pass. The chatbot does not need real identifiers to improve your wording.
Does the passive voice rule mean passive voice is wrong?
No. Passive is the right construction when the actor is unknown, irrelevant, or better left unstated — lab reports and incident writeups use it deliberately. The rule surfaces every instance so you can see the pattern and decide case by case; that is different from a blanket prohibition.
Can I use the checker without an account?
Yes. It is a browser tool with no sign-up step — open the page, paste or drop your text, and the underlines and readability report appear in the tab. Nothing is stored on a server because nothing is sent to one.
