Harper 2.6: Is the Offline Grammar Checker Ready to Replace Grammarly?

Harper's strongest reason to adopt is not that it catches every error a cloud writing assistant can catch. It does not. The value is a narrower contract: check English spelling and grammar on the device, return deterministic suggestions quickly, and keep the engine inspectable under the Apache 2.0 license.

That trade is newly relevant. LanguageTool has moved its browser extension behind Premium for users who do not connect a self-hosted server, while teams remain uneasy about sending emails, drafts, support replies, source comments, and internal documents to a remote writing service. Harper 2.6.0 offers a free local browser extension, editor integrations, a language server, a Rust core, and a WebAssembly library without putting an LLM in the correction path.

The OpenSourceChoice verdict is qualified: Harper is ready for an English-first personal workflow and a controlled team pilot when privacy and latency matter more than deep contextual rewriting. It is not a complete Grammarly or LanguageTool replacement for multilingual writers, complex agreement errors, tone rewriting, or teams that require a mature vulnerability-disclosure process.

This is a researched technical review of Harper 2.6.0 and the upstream state observed on July 24, 2026. OpenSourceChoice did not install Harper, capture its network traffic, benchmark its accuracy or latency, audit its source code, or compare it against a paid grammar service on a controlled corpus.

Executive verdict

Adopt Harper first for browser text fields, Markdown, code comments, commit messages, and Obsidian notes that are primarily English and may contain private material. Start with one integration, turn off noisy rules, add organization-specific terms to a dictionary, and measure its suggestions against writing your team actually produces.

Do not treat "offline" as a substitute for evaluation. A browser extension that checks every text field needs broad page access, a system-wide desktop utility needs operating-system accessibility privileges, and a local rules engine can still miss errors or propose false corrections. The relevant question is not whether Harper is private in principle, but whether the exact packaged integration has the permissions, update path, accuracy, and failure behavior your workflow can accept.

The best parallel comparison is a self-hosted LanguageTool server when multilingual grammar depth matters. Documentation teams should also compare Vale, which is better suited to versioned editorial rules and CI even though it is not an interactive replacement for a full grammar checker.

Why this matters now

Harper has more than one current interest signal:

• it appeared on GitHub Trending on July 24;
• a July 22 discussion in r/selfhosted focused on Harper as a local Grammarly alternative;
• separate July discussions in the Obsidian and non-AI writing communities repeatedly recommended it for local, deterministic checking;
• LanguageTool's current policy makes its normal browser-extension workflow a Premium feature, while explicitly retaining self-hosting for developers.

The project is active rather than riding an abandoned repository. The latest stable GitHub release is v2.6.0, published June 24, 2026. GitHub's API returned 95 commits from June 24 through the latest commit on July 23, with changes from multiple contributors. At the same time, 561 open issues and 122 open pull requests were visible on July 24. Those counts are not a quality score, but they show both sustained participation and a substantial review queue.

The timing is therefore about a real adoption decision, not a single viral post: accept a narrower local checker, pay for a managed writing assistant, or operate a more capable server yourself.

What Harper actually is

Harper is closer to a programmable linter for English than to a generative writing assistant.

Its architecture has three important layers:

1. harper-core tokenizes, parses, analyzes, and lints English text in Rust. Linters query the resulting document and emit a problem plus possible corrections.
2. harper-ls exposes the engine through the Language Server Protocol. Editors such as VS Code, Neovim, Helix, Emacs, Zed, and Sublime Text can consume the same local diagnostics.
3. harper.js compiles the core to WebAssembly and loads it from JavaScript or TypeScript. It powers browser-facing integrations and can be embedded in web or Node applications.

The official distribution surface is broader than the core:

• Chrome-family and Firefox extensions;
• Obsidian and WordPress integrations;
• editor extensions and the language server;
• portable release binaries, Scoop, Homebrew, Arch, Nix, and Cargo installation paths;
• a macOS desktop application that checks system text fields.

The desktop application is still labeled beta and currently requires macOS 14 or later. The project says Windows and Linux system-wide desktop support is not available yet. Windows and Linux users can still use the browser, editor, language-server, and command-line paths.

What it deliberately does not do

Harper is not an LLM wrapper. That removes cloud inference, prompt injection, generative drift, and per-request model cost from its normal correction path. It also removes capabilities people now expect from AI writing assistants.

Harper does not provide:

• multilingual grammar checking; the core currently supports English;
• open-ended rewriting, summarization, translation, or tone transformation;
• semantic fact checking or source verification;
• plagiarism or AI-generated-text detection;
• a hosted team console for policy, analytics, and centralized administration;
• guaranteed understanding of long-range context or intent.

It supports American, British, Canadian, Australian, and Indian English dialect settings, but dialect choice is not the same as multilingual support. Mixed-language isolation exists in harper-ls, and the documentation calls it new and unstable.

That scope is a feature when a team wants a predictable spell-and-grammar layer. It is a hard limit when the real job is developmental editing, multilingual customer communication, or rewriting a weak paragraph while preserving meaning.

Accuracy is the main adoption risk

Harper's maintainers publish a comparison that reports a 10 ms suggestion time, versus higher values for LanguageTool and Grammarly. Treat those numbers as the project's benchmark, not an independent result. The comparison does not establish which tool catches more relevant errors, how false-positive rates differ, or how performance changes across integration, document size, hardware, and rule configuration.

The open issue tracker makes the quality boundary visible. A long-standing open feature request covers subject-verb number agreement. A July 22 harper-ls issue reports that an orthographic-consistency rule could not be disabled and flagged common technical filenames such as index.html and package.json. Other current issues track false positives and language coverage.

This does not make Harper unusable. It means teams should evaluate it like a static-analysis tool:

• define the error classes that matter;
• measure missed errors and distracting suggestions separately;
• test prose, code comments, filenames, product names, and abbreviations;
• keep dictionaries and rule configuration under review;
• retain human review for consequential writing.

Determinism is useful here. A given version and configuration should make repeatable suggestions, so regressions can be caught with a fixed corpus. That is a better operational property than accepting an opaque model update, but it does not guarantee linguistic coverage.

Privacy: local processing, broad integration privileges

Harper's browser and desktop documentation says text analysis runs locally, with no account, cloud round-trip, telemetry, or LLM in the normal correction path. The Firefox add-on listing for version 2.6.0 nevertheless requires permission to access browser tabs and data on all websites. Those privileges are unsurprising for an extension that checks arbitrary text fields, but they define a large trust boundary.

Local processing reduces one risk: text does not need to be sent to a grammar vendor for every correction. It does not eliminate:

• malicious or compromised extension updates;
• a defect that reads or alters the wrong page content;
• exposure to password fields, financial systems, legal portals, or regulated data;
• optional user-triggered issue reports or links that contact project infrastructure;
• local compromise of the browser profile or workstation;
• system-wide accessibility access granted to the macOS desktop beta.

For sensitive use, prefer a constrained integration. A language server limited to approved repositories has a smaller reach than a browser extension with access to every website. If the browser extension is necessary, restrict site access where the browser permits it, disable it on secret-management and regulated applications, manage updates, and verify the packaged version rather than assuming every distribution channel ships simultaneously.

Release channels are not synchronized

The v2.6.0 GitHub release included portable binaries and integration artifacts on June 24. Firefox listed extension version 2.6.0, updated July 2. On July 24, the crates.io stable versions for harper-core and harper-ls were 2.5.0, while npm served harper.js 2.4.0.

Version skew does not necessarily indicate a defect: different integrations may release on different schedules, and browser stores add their own review delay. It does make "we use Harper 2.6" ambiguous.

Record four values in a production inventory:

• the engine or package version;
• the integration version;
• the distribution source;
• the rule and dictionary configuration.

Developers embedding harper.js should be especially cautious. Its official documentation labels the package early access and says the API is not yet stable. Pin the package, test upgrades, and isolate it behind a small internal adapter.

Security posture

Harper's GitHub security page reported no SECURITY.md policy and no published repository advisories on July 24. Queries against OSV returned no vulnerabilities for harper-core 2.5.0, harper-ls 2.5.0, or harper.js 2.4.0 at research time.

An empty advisory record is not proof that no vulnerability exists. The absence of a documented private reporting route is the more important organizational gap, particularly for software distributed as browser extensions and a system-wide desktop utility.

Before a team-wide rollout:

• verify release checksums or trusted store provenance;
• review extension permissions and enterprise site-access controls;
• test whether correction text appears in unexpected outbound requests;
• document how to disable or roll back a bad update;
• scan the exact package and its dependencies;
• decide where a security report would be sent if a private policy is still absent;
• keep the integration away from secrets and high-consequence forms by default.

For an individual writer, this may be an acceptable gap relative to a cloud service. For a regulated organization, it may be a procurement blocker until a formal vulnerability-reporting channel and response commitment exist.

License, commercial use, and lock-in

Harper is licensed under Apache 2.0. The license permits use, modification, redistribution, and commercial embedding, subject to its notice and attribution conditions, and includes an express patent grant. It does not grant rights to Automattic or Harper trademarks.

The code-level exit path is strong: the Rust core, WebAssembly wrapper, language server, dictionaries, and rule implementation are available. Documents remain ordinary text, and user and workspace dictionaries are plain line-separated files.

Configuration is not universally portable. Harper rule names, ignored-lint files, and Weirpacks belong to the Harper ecosystem. If those become editorial policy, keep the human-readable policy outside the tool as well, then map it to Harper, Vale, or another checker. That prevents a local grammar engine from becoming the only copy of an organization's writing standard.

The real operating cost

The software price can be zero, and the normal local workflow needs no hosted inference or server. Adoption still has a labor cost:

• selecting and managing the integration;
• reviewing broad browser or desktop permissions;
• curating dictionaries for product names and technical terms;
• tuning rules to control false positives;
• maintaining a representative quality corpus;
• pinning and qualifying releases across unsynchronized channels;
• training writers to treat suggestions as proposals rather than facts;
• retaining human review for legal, medical, financial, or public commitments.

The lowest-cost path is a personal browser or editor installation with default rules. The most controllable team path is harper-ls or the CLI in approved repositories, with dictionaries and configuration versioned beside the content. Embedding harper.js has no per-request fee but creates application integration and upgrade work.

Self-hosting is not really the Harper decision because the core service is not remote in the first place. The decision is how much of the workstation or browser to expose to the local checker.

Who should adopt Harper

Harper is a good fit for:

• writers who work mainly in English and want corrections without cloud text processing;
• developers checking Markdown, comments, documentation, and commit messages;
• Obsidian users who want local inline suggestions;
• small teams prepared to maintain dictionaries and rule settings;
• applications that need an embeddable deterministic grammar layer;
• workflows where a lightweight checker is useful even when it is not exhaustive.

It is a weak fit for:

• multilingual teams;
• users who need paragraph rewriting, tone control, translation, or deep contextual suggestions;
• organizations that require a mature security policy and vendor support contract;
• Windows or Linux users seeking a system-wide desktop experience today;
• teams that will accept every correction automatically;
• regulated workflows that cannot grant an extension access to arbitrary page data.

Alternatives to evaluate in parallel

LanguageTool is the primary comparison when language coverage and more advanced grammar rules matter. Its open-source server supports more than 20 languages and can run locally, but the official documentation describes it as an advanced command-line deployment and notes that cloud-only AI rules are not included. Its browser extension now requires Premium for the normal hosted service, while users connected to their own server can continue using it. Choose this path when operating a Java service is justified by multilingual or deeper checking needs.

Vale 3.14.2 is better for documentation teams that want an offline, markup-aware style linter in local development and CI. It enforces vocabulary and editorial style consistently across a repository. It is not a system-wide browser checker and should not be expected to understand general English as deeply as a grammar product.

CSpell is a smaller option for source repositories when spelling, project terminology, and CI are the actual requirements. It does not replace grammar checking, but its narrower purpose can produce less noise in technical content.

Built-in browser and operating-system spell checking remains the control option. It adds no third-party all-sites extension and may be sufficient when the risk of missed grammar is lower than the risk of broad page access.

A measurable seven-day pilot

Use one integration and one stable package path. Do not combine the browser extension, desktop beta, and language server in the first evaluation.

1. Collect 200 to 500 representative sentences from approved, non-sensitive writing. Include known spelling, agreement, punctuation, capitalization, technical-term, and style cases.
2. Mark the expected findings before running Harper. Keep a clean copy that can be reused for later versions.
3. Record the exact engine, integration, source, dialect, enabled rules, and dictionary.
4. Measure recall on the error categories that matter and false positives per 500 words. Do not score harmless style preferences as critical errors.
5. Capture network activity while checking synthetic text. Require no unexpected request containing the text.
6. Test technical filenames, code blocks, product names, mixed-language passages, long files, and applications where the extension must remain disabled.
7. Repeat the corpus with LanguageTool or Vale, depending on whether grammar depth or editorial consistency is the parallel requirement.

A reasonable team can set explicit gates such as:

• at least 80% of its predefined high-priority errors detected;
• no more than one distracting false positive per 500 words;
• no checked text observed in unexpected outbound traffic;
• no access to excluded high-risk sites;
• a documented rollback and version-pinning path;
• no material regression when the next version is tested on the same corpus.

These are proposed acceptance thresholds, not results measured by OpenSourceChoice. Raise or lower them according to the cost of a missed error and the sensitivity of the text.

OpenSourceChoice assessment

• Best for: English-first writers and developers who value local, deterministic checking.
• Not for: Multilingual, generative rewriting, or high-assurance enterprise workflows without additional controls.
• Why now: Current GitHub and community interest aligns with LanguageTool's paid browser-extension shift.
• Real cost: Rule tuning, dictionaries, permission review, corpus testing, and package-version management.
• Main risk: Limited linguistic coverage combined with broad integration privileges and no formal security policy.
• Production gate: Pass a representative accuracy corpus and a network/permission review using the exact packaged integration.
• Parallel alternative: Self-hosted LanguageTool for multilingual grammar; Vale for repository style enforcement.
• Recommendation: Adopt personally, pilot in a small English-first team, and keep human review for consequential text.

Sources

Primary sources, accessed July 24, 2026 unless otherwise noted:

• Harper repository and current README — Automattic; architecture surface, license, language scope, repository activity, and current issue/PR state.
• Harper v2.6.0 release — Automattic; released June 24, 2026; current stable release notes and artifacts.
• Harper architecture — Automattic; harper-core, harper-ls, and harper.js responsibilities.
• Language server documentation and integration catalogue — Automattic; installation methods, supported editors, dialects, dictionaries, and integration requirements.
• Harper Desktop — Automattic; beta status, macOS requirements, local-processing claims, and Windows/Linux roadmap statement.
• Harper security overview — Automattic on GitHub; security-policy and published-advisory state.
• Apache 2.0 license — Automattic; current repository license terms.
• Firefox add-on listing — Mozilla Add-ons; version 2.6.0, updated July 2, 2026; required permissions and package size.
• Subject-verb agreement issue and technical-term false-positive issue — Automattic issue tracker; open grammar-coverage and integration limitations.
• harper.js documentation, npm package, and harper-ls crate documentation — official documentation and registries; early-access warning and package versions observed July 24, 2026.
• LanguageTool browser-extension announcement and self-hosted server documentation — LanguageTool; current Premium policy and local server boundary.
• Vale v3.14.2 release — vale-cli; released May 15, 2026; current comparison version.

Trend-discovery and community-perspective sources, not used as primary evidence for technical claims:

• GitHub Trending — observed July 24, 2026.
• Harper self-hosted discussion — Reddit r/selfhosted; posted July 22, 2026.
• Non-AI grammar-checker discussion — Reddit r/FanFiction; posted July 1, 2026.
• Obsidian grammar-checker discussion — Reddit r/ObsidianMD; posted July 8, 2026.