A local checker with a deliberately narrow job
Harper checks English spelling, grammar, usage, and style without uploading the text. Its Rust core compiles to WebAssembly for browser extensions, Obsidian, Node.js, and embedded web products. A Language Server Protocol frontend brings it into VS Code, Neovim, Helix, Emacs, Zed, and other editors. There is also a desktop editor, a command-line frontend, and a WordPress integration.
This is not a generative writing assistant. Harper identifies a rule violation and offers a focused correction. That narrower scope is a virtue when the document is private, the network is unavailable, or the writer does not want paragraphs rewritten into a generic voice. Local analysis also removes request latency and the need to operate a grammar server. The Apache 2.0 license makes the engine practical to embed.
English is the firm boundary. The main README explicitly says no other language is currently supported. Contributions for additional languages are welcome, and active work explores that direction, but an open pull request is not shipped support. A multilingual team should choose based on today's English checker, not the extensibility claim.
The language server is the strongest developer experience
harper-ls is the most convincing route for technical writing. It parses Markdown and comments in many programming languages, then returns diagnostics and quick fixes through a standard editor protocol. Installation options cover Homebrew, Scoop, Arch Linux, Nix, Termux, Cargo, and portable binaries. Most developers can get the server installed without cloning the monorepo.
Dictionary handling is unusually thoughtful. Harper combines a global user dictionary, a workspace word list, file-specific dictionaries, and its built-in static data. A product name can belong to one repository without polluting every document, while a person's name can be limited to one file. Code actions add a word at the right scope or ignore a lint for the session. Existing CSpell ignore-comment forms are recognized, which reduces migration friction for teams that already annotate source files.
Rules are individually configurable. Teams can enable or disable spelling, long-sentence warnings, repeated words, capitalization, punctuation, number style, and many more checks. This is essential because editorial judgment varies. A documentation team should commit its workspace dictionary and configuration, then review changes to those files like code. Otherwise each writer ends up seeing a different product vocabulary and rule set.
Browser and application use is appealing, with caveats
Chrome and Firefox users get the simplest experience: install the extension and write as usual. The documentation says analysis stays local in both browsers. That makes Harper attractive for email, private notes, internal documents, and draft posts. Chrome releases may arrive a few days after other integrations because of store review, a small but clearly documented lag.
For product teams, harper.js packages the core engine as an ECMAScript module backed by WebAssembly. It can run in browsers or Node.js and already powers Harper's own web surfaces and Obsidian plugin. The catch is explicit: the package is early access and its API is not stable. Embedding it today is reasonable for a team that can pin a version and absorb migration work, not for a plug-in contract that must remain unchanged across unattended updates.
The desktop application is also a qualified choice. Its README says it currently does little beyond an offline Markdown editor with Harper built in, and warns that documentation is incomplete. The v2.7.0 release notes describe it as beta. Use it if that exact minimal editor appeals to you. Do not choose it expecting document collaboration, layout tools, or a finished replacement for a full word processor.
Automation and scale expose unfinished edges
Harper has a CLI, but the project calls it experimental and feature-barren. Its stated use is checking many files, including in continuous integration, yet machine-readable output, on-disk caching, and custom dictionaries are only listed as possible future features. That gap matters in CI, where stable structured output and repository vocabulary are basic requirements. Vale or CSpell is a better automation choice until the CLI grows a firmer contract.
The local architecture is light for the built-in English dictionary, but arbitrary dictionary scale is not solved. Issue 3725 reports that the current FST dictionary implementation retains multiple materialized forms of a large word list. The reporter found that a highly inflected Slovak dictionary consumed substantial resident memory and identified this as a blocker for that language. Those measurements do not describe normal English use, but they are relevant to anyone extending the core with millions of generated forms.
Grammar checkers also live on false positives and missed phrases. Harper's activity stream includes both new corrections and fixes for phrases that were wrongly flagged. This is healthy maintenance, but it means teams should test their real prose, tune noisy rules, and resist applying every suggestion automatically. The project is a reviewer, not an authority.
Health, documentation, and the choice
Harper was pushed on August 10, 2026, and version 2.7.0 shipped on July 28. GitHub listed 14,325 stars and 737 open issues and pull requests on August 10. That combined count is large, but same-day pull requests, bug reports, fixes, dictionary work, and rule additions show an exceptionally active queue. The latest release alone included many phrase rules, false-positive fixes, performance work, editor improvements, and several first-time contributors.
Documentation is strong where the project is mature. The language-server guide explains installation, dictionary scopes, code actions, ignore comments, configuration, and rules. Browser and JavaScript guides clearly state their privacy model and release status. The CLI and desktop documents are candidly sparse, which is preferable to pretending those surfaces are finished.
For private English checking, Harper deserves to be tried before a cloud assistant. The browser extensions are effortless, and harper-ls fits a developer's normal editing loop without sending unpublished work away. Choose LanguageTool for multiple languages, Vale for policy-driven prose CI, or CSpell for code-heavy spelling. Choose Harper when local English grammar feedback is the actual job, and keep human judgment in the loop.