Harper: A Rust-based grammar checker that runs offline and in your browser

The problem: online grammar checkers are slow and intrusive

Harper was created to fix what its author saw as the two main shortcomings of existing grammar checkers. Grammarly is described as expensive, overbearing, and a privacy nightmare, because everything you write is sent to its servers. LanguageTool is positioned as the opposite: it is open source, but it needs gigabytes of RAM and a 16GB n-gram dataset, and it takes several seconds to lint a moderate-size document. Harper sits between these two. It is an English grammar checker that runs entirely offline, so no text leaves your machine. The README claims it takes milliseconds to lint a document and uses less than 1/50th of LanguageTool's memory. That combination is the core value proposition: speed and privacy without the heavy resource cost.

How it works: a Rust core that compiles to native and WebAssembly

Harper is written in Rust, which is what allows it to be both fast and small. The README says it is small enough to load via WebAssembly, and the homepage at writewithharper.com hosts a web version. The architecture is not described in detail in the material, but the repository layout shows a language server component called harper-ls, which is published on crates.io. That suggests the core linting logic is exposed through a language server protocol, which editors like VS Code, Neovim, Helix, Emacs, and Zed can connect to. There is also a JavaScript wrapper called harper.js, which likely compiles the Rust core to WebAssembly for use in browsers or Node.js. The README mentions the core is extensible to support other languages, but only English is implemented. The actual grammar rules and parsing pipeline are not documented in the material, so the exact mechanism remains opaque from these files alone.

Getting it running: editor integrations and the language server

The README links to documentation for five editors: Visual Studio Code, Neovim, Helix, Emacs, and Zed. It also links to a dedicated page for Obsidian, which suggests a plugin exists for that note-taking app. The language server, harper-ls, is the central piece. You can install it from crates.io, which means you build it with cargo, the Rust package manager. A typical command would be cargo install harper-ls, though the README does not show that exact command. Once installed, you configure your editor to talk to the language server via LSP. For Neovim, you would add harper-ls to your LSP client settings. For VS Code, you would install the extension from the marketplace. The documentation pages likely contain exact config keys, but the README only provides links. There is also harper.js for web-based use, which you would import as a JavaScript package. The web version at writewithharper.com is the quickest way to try it without installing anything.

Performance as a design principle, not an afterthought

The README has a section titled 'Performance Issues' that states: 'We consider long lint times bugs.' That is an unusual stance for a grammar checker, and it tells you how the project prioritizes speed. It also says that if you encounter significant performance issues, you should create an issue, and if you fix one, you should contribute. This is a concrete commitment: the maintainers treat slowness as a defect, not an acceptable trade-off. That is relevant if you are evaluating Harper for interactive use, where you want suggestions as you type without a noticeable delay. The claim of milliseconds per document is impressive, but it is a claim from the README, not a benchmark you can verify from the material. Still, the design goal is clear.

Limitations: English only, and the core is the only real target

The most obvious limitation is language support. Harper only works on English text. The README says the core is extensible, but no other language is implemented. If you write in Spanish, French, or German, Harper is not for you. Another limitation is that the grammar rules are not described. The README does not list what kinds of errors it catches: punctuation, style, subject-verb agreement, or something else. You have to try it to find out. There is also no mention of a CLI tool for batch-processing files, only the language server and the web version. If you want to lint a whole directory from the command line, you may need to write a script that uses harper-ls or harper.js. The project is also young in terms of releases, with the latest being v2.9.1, so the rule set may be less mature than LanguageTool's.

The alternative: LanguageTool, with its memory and data trade-offs

The main open-source alternative is LanguageTool. The README explicitly compares Harper to it, so it is fair to use that comparison here. LanguageTool supports many languages, which is its biggest advantage. It also has a richer rule set and a long history. But it requires a 16GB n-gram dataset and gigabytes of RAM, and it is slow, taking seconds to lint a moderate document. Harper trades language coverage and rule depth for speed and a tiny memory footprint. If you need multi-language support or you are willing to pay the resource cost, LanguageTool is the better choice. If you write only in English and value responsiveness and privacy, Harper is designed for you.

Maintenance and licensing: Apache-2.0 and active development

Harper is licensed under Apache-2.0, which is a permissive open-source license. You can use, modify, and distribute it, even in commercial products, as long as you include the license and notice. That is a low barrier for adoption. The repository is not archived, and the last push was on 2026-08-29, which is recent. Releases are frequent: v2.7.0 in July 2026, v2.8.0 in August, and v2.9.1 at the end of August. That indicates active maintenance. The project is part of Automattic, the company behind WordPress, which gives it some institutional backing. The README asks contributors to read the contribution guidelines, which suggests there is a defined process for adding rules or fixing bugs. Upgrade cost is not documented, but the language server protocol is stable, so updating harper-ls to a new version should not break your editor config. The web version is hosted, so you get updates without any action.

Editorial conclusion

Adopt Harper if you are a writer or developer who wants a grammar checker that runs entirely offline, is fast enough for interactive use, and does not send your text to a server. It is also a good fit if you are constrained by memory, since it claims to use less than 1/50th of LanguageTool's footprint. Do not adopt it if you need grammar checking in languages other than English, as only English is currently supported. Before adopting, verify that the editor integration you need is available and that the linting speed meets your expectations, since the project treats long lint times as bugs and expects you to report them.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes