RepoDaily · 2026-07-24 · Infrastructure / Runtime

Harper: A Rust-Powered Grammar Checker That Runs Entirely on Your Machine

#11 Infrastructure / Runtime Rust +590 Automattic/harper Open repository

Automattic's open-source grammar checker lints documents in milliseconds, uses 1/50th of LanguageTool's memory, and never sends a single word to a server.

Repo typeInfrastructure / Runtime
Best forDevelopers and writers who want millisecond grammar checking inside their editor or browser without any text leaving the device.
Risk levelLow — Apache 2.0, backed by Automattic, runs fully offline with no network calls.
Time to evaluateUnder 10 minutes — install harper-ls or harper.js and point your editor at it.

Primary question: Do you need a grammar checker that never transmits your text to a third-party server?

91/100

RepoDaily adoption score

RepoDaily rates this as 91/100 (strong) for adoption: evidence, installation path, production risk, differentiation, license clarity, and AI/agent fit are scored from the article sources and adoption notes.

Directional score from RepoDaily sources and adoption notes, not a benchmark.Risk: Low
100Evidence quality

5 source(s) across 3 source category/categories, plus a RepoDaily-specific evidence module when available.

97Installability

5 workflow step(s), 5 next-action step(s), and 2 command/install signal(s) were detected.

72Maintenance confidence

Trending momentum is +590 stars, with maintenance/release/issue signals counted when present.

100Production readiness

Risk is marked low, with 4 security note(s) and 3 explicit skip condition(s).

100Differentiation

3 opportunity lens item(s), 3 alternative(s), and 4 type-specific section(s) support differentiation.

82License clarity

License source or license wording is present.

66Agent / AI fit

3 AI/agent-related signal(s) were detected in the article text and metadata.

Project overview

Harper is an English grammar checker built in Rust and maintained by Automattic, the company behind WordPress.com. It is designed to fill a gap that its author describes plainly: Grammarly is expensive, overbearing, and sends everything you write to remote servers, while LanguageTool demands roughly 16 GB of n-gram data and takes several seconds to lint a moderate-size document. Harper takes a different path — it lints in milliseconds, occupies less than one-fiftieth of LanguageTool's memory footprint, and processes text entirely on the device where it runs.

The project ships as several discrete artifacts: a command-line interface (harper-cli), a Language Server Protocol implementation (harper-ls) published on crates.io, a WebAssembly build (harper.js) distributed via NPM, a desktop application built on Tauri, and an Obsidian plugin. The language server integrates with VS Code, Neovim, Helix, Emacs, and Zed, giving developers grammar checking directly inside the editors they already use.

What makes Harper architecturally interesting is that the Rust core is intentionally split into focused workspace crates — harper-core for the linting engine, harper-ls for the language server, harper-wasm for browser deployment, harper-tree-sitter and harper-html for parsing structured text, and domain-specific crates like harper-typst, harper-tex, harper-python, and harper-asciidoc for different document formats. This separation means the same grammar engine can power an editor plugin, a CLI tool, a web app, or a documentation pipeline without duplicating logic.

The project is licensed under Apache 2.0, which permits commercial use, modification, and redistribution. Combined with the fact that all processing is local, this makes Harper viable for organizations with strict data-residency requirements — regulated industries, confidential drafting, or simply writers who do not want their prose used to train language models.

Problem it solves

  • Grammarly sends user text to remote servers, and the README notes its privacy policy does not prevent using that data to train large language models.
  • Grammarly's suggestions are described as lacking context and frequently wrong, with a round-trip network latency that slows revision.
  • LanguageTool requires roughly 16 GB of n-gram data and gigabytes of RAM, making it impractical for lightweight or embedded use.
  • LanguageTool takes several seconds to lint a moderate-size document — Harper considers anything beyond milliseconds a bug worth filing.
  • Cloud grammar services create compliance and confidentiality concerns for regulated industries and sensitive drafts.

How it works

  1. Install the integration that matches your environment: harper-ls from crates.io for editor integration via Language Server Protocol, or harper.js from NPM for web and Node.js contexts.
  2. Configure your editor — the documentation covers VS Code, Neovim, Helix, Emacs, and Zed with editor-specific setup pages on writewithharper.com.
  3. Open a document; the Rust linting engine analyzes text locally and returns suggestions in milliseconds with no network round-trip.
  4. For browser-based use, load the WebAssembly build, which is small enough to serve as a static asset with no server-side component.
  5. Optionally extend the engine with new language support — the core is designed to be extensible beyond English, and contributions are welcomed.

Workspace Architecture: How the Rust Crates Fit Together

Harper's Cargo.toml defines a large workspace with 22 members, each handling a specific concern. The core linting logic lives in harper-core. The Language Server Protocol wrapper is harper-ls, published on crates.io. Browser deployment uses harper-wasm, distributed as harper.js on NPM. Parsing of structured or code-adjacent text is delegated to harper-tree-sitter, harper-html, harper-comments, harper-python, harper-literate-haskell, and harper-ink.

Document-format support is spread across harper-typst, harper-tex, harper-asciidoc, and harper-html. Utility crates include harper-stats for metrics, harper-pos-utils for part-of-speech tooling, harper-thesaurus for synonym handling, and harper-brill for Brill tagger logic. The desktop application is built with Tauri (harper-desktop/src-tauri), and harper-git-commit provides commit-message linting.

The release profile uses opt-level 3, panic set to abort, and fat LTO — choices that prioritize binary size and runtime speed. The test profile applies opt-level 1 to the local crate and opt-level 3 to dependencies, keeping test runs fast without slowing dependency-heavy integration tests.

Integration Surface: Where You Can Plug Harper In

  • harper-ls on crates.io — Language Server Protocol server for any LSP-capable editor.
  • harper.js on NPM — WebAssembly build for browser and Node.js embedding.
  • Obsidian plugin — separate repository (harper-obsidian-plugin) with its own download tracker.
  • Desktop app — Tauri-based native application for standalone use.
  • Editor docs — dedicated setup pages for VS Code, Neovim, Helix, Emacs, and Zed at writewithharper.com/docs/integrations/.
  • harper-cli — command-line interface for scripting and CI linting of text files.

Fastest Path to Try It

If you use a supported editor, the quickest evaluation is installing harper-ls and pointing your LSP client at it. The docs site (writewithharper.com/docs/integrations/) has editor-specific pages for VS Code, Neovim, Helix, Emacs, and Zed.

For web developers, the NPM package harper.js provides the WebAssembly build. The package.json requires Node >= 22 and pnpm ^10.6.3 for the repository's own development scripts, which use Biome for formatting. The README confirms the WASM build is small enough to load via WebAssembly in a browser, and writewithharper.com itself is a live demonstration.

Obsidian users can install the plugin from the separate harper-obsidian-plugin repository. The README links to dedicated Obsidian documentation at writewithharper.com/docs/integrations/obsidian.

How Harper Compares to Grammarly and LanguageTool

The README is unusually direct in positioning Harper against its two main competitors. Grammarly is described as expensive, overbearing, lacking context in its suggestions, and a privacy nightmare because all text goes to its servers. The README specifically calls out that Grammarly's privacy policy not selling data does not prevent using it for model training.

LanguageTool is described as great in capability but impractical in resource use — it needs roughly 16 GB of n-gram data and several seconds to lint a moderate document. Harper claims less than 1/50th of LanguageTool's memory footprint and millisecond lint times.

Vale, another open-source prose linter, focuses on style rules and configurable linting rather than grammar correction, making it complementary rather than a direct replacement for Harper's grammar-focused suggestions.

Who should pay attention?

Good fit if

  • Individual writers and developers who want grammar checking without cloud data transmission.
  • Teams standardized on VS Code, Neovim, Helix, Emacs, or Zed who can benefit from LSP-based linting.
  • Obsidian users who want in-app grammar suggestions from a plugin.
  • Web application developers who need an embeddable grammar checker via WebAssembly with no backend.
  • Organizations in regulated industries where text must not leave the local machine.

Skip for now if

  • Non-English content — Harper currently supports only English, though the core is extensible.
  • Users who need broad multi-language grammar checking today without writing their own language pack.
  • Teams that prefer cloud AI rewriting and tone-adjustment features over rule-based grammar correction.

Risks and cautions

Low

Apache 2.0 license, backed by Automattic, runs entirely offline with no network dependency or data transmission.

  • Apache 2.0 permits commercial use, modification, and redistribution with patent grant.
  • All text processing is local — the README confirms no data is sent to servers and the WASM build runs client-side.
  • Published on crates.io (harper-ls) and NPM (harper.js) with visible CI badges for binaries, web builds, and checks.
  • Backed by Automattic, providing institutional continuity beyond a single maintainer.
  • Performance regressions are explicitly treated as bugs per the README, indicating a quality-first stance.
  • All grammar analysis happens on the local machine — no text is transmitted to any server.
  • The WebAssembly build runs entirely in the browser with no backend calls.
  • Apache 2.0 license permits source-code audit and modification for security review.
  • The README directly contrasts Harper's local processing with Grammarly's server-based model and its data-training concerns.

Alternatives to compare

ApproachWhen to useTrade-off
Grammarly
You want cloud-powered AI rewriting, tone adjustment, and cross-platform browser integration.Subscription-based commercial product.
LanguageTool
You need multi-language grammar support beyond English and can allocate gigabytes of RAM and a 16 GB n-gram dataset.Free open-source or paid cloud service.
Vale
You want a prose linter focused on configurable style rules rather than grammar correction.Free open-source (MIT).

What this trend reveals

Embed grammar checking in web apps with harper.js

The WebAssembly build is small enough to load as a browser asset. Web editors, CMS drafting interfaces, and form-heavy SaaS products can offer real-time grammar suggestions without a backend grammar API, eliminating both latency and data-privacy concerns.

Install harper.js from NPM, load the WASM module in a browser test page, and benchmark lint latency on a 2,000-word document to confirm the millisecond claim for your target environments.

Lint documentation and commit messages in CI

The workspace includes harper-git-commit for commit-message linting and harper-cli for command-line use. Documentation pipelines for Typst, LaTeX, AsciiDoc, and HTML can integrate Harper to catch grammar errors before merge.

Run harper-cli against a sample documentation directory and measure how many suggestions it surfaces per 1,000 words compared to your current review process.

Contribute a new language pack

The README explicitly states the core is extensible to support other languages and welcomes contributions. Teams with in-house linguistics expertise can add language support that runs with the same local-first, low-memory characteristics.

Review the contribution guidelines at writewithharper.com/docs/contributors/introduction and prototype a minimal rule set for a target language using harper-core as the foundation.

Best next action

Install harper-ls and connect it to your primary editor

The fastest way to evaluate Harper is to run the language server in the editor you already use. This gives you real-time grammar suggestions on actual documents within minutes.

  1. Install harper-ls from crates.io or your system package manager.
  2. Follow the editor-specific setup page at writewithharper.com/docs/integrations/ for VS Code, Neovim, Helix, Emacs, or Zed.
  3. Open a real document you are drafting and review the suggestions Harper produces.
  4. Compare lint speed and suggestion quality against your current grammar tool on the same text.
  5. If you build web apps, also test harper.js from NPM in a browser sandbox to confirm the WASM build meets your latency targets.

RepoDaily verdict

Harper is the rare grammar tool that a developer can recommend without privacy caveats: it is Apache 2.0, backed by Automattic, written in Rust, and runs entirely on-device. With multi-editor LSP support, a browser-loadable WASM build, and an explicitly extensible core, it is well worth trying for anyone who has been dissatisfied with Grammarly's cloud model or LanguageTool's resource appetite.

Sources