Open-source alternatives to Grammarly: 4 writing and grammar assistant tools compared
Replacing Grammarly means running the checker yourself and keeping the rule set, the language coverage and the client surface under your own control, and the four candidates here disagree about what a checker is: a language engine, a runner with no rules, a fixed catalogue of style checks, or a wiki that checks nothing. Most readers should look at languagetool-org/languagetool first, because it is the only one that checks grammar in languages other than English.
What Grammarly does, and why people look elsewhere
Grammarly is a hosted writing assistant that checks spelling, grammar and style in a document and suggests rewrites, through a browser extension and an editor integration.
- the text you write is sent to the vendor's servers to be checked
- the suggestion engine is the vendor's and the rules it applies are not yours to change
- the browser extension needs the service to be reachable, so checking stops when it is not
The candidates at a glance
| Project | Licence | Maintenance | Language | GitHub stars | Install |
|---|---|---|---|---|---|
| languagetool-org/languagetool | LGPL-2.1Weak copyleft: changes to its own files stay open | Commits in the last dayLast push October 22, 2026 | Java | 15,179 | Command documented |
| textlint/textlint | MITPermissive: commercial use allowed | Commits in the last six monthsLast push October 18, 2026 | TypeScript | 3,202 | Command documented |
| amperser/proselint | BSD-3-ClausePermissive: commercial use allowed | Commits in the last six monthsLast push September 4, 2026 | JavaScript | 4,587 | Command documented |
| Smaug6739/Alexandrie | MITPermissive: commercial use allowed | Commits in the last six monthsLast push October 18, 2026 | Vue | 3,324 | Command documented |
Each alternative in detail
languagetool-org/languagetoolStyle and Grammar Checker for 25+ Languages
- Best for
- A team that needs grammar and style checking in a language other than English, or behind an HTTP API it controls, and can afford to run a JVM service.
- What you give up
- It ships no client that checks as you type in a browser; the README points at an HTTP server, a Java API and a LibreOffice or OpenOffice extension package, so a live editor integration is yours to build. A complete clone downloads more than 500 MiB and needs more than 1 500 MiB of disk, and the Docker images listed in the README are community-contributed rather than built by the project.
- Moving from Grammarly
- Text reaches the checker over the documented HTTP API, and the installer offers an office-extension package that adds it to LibreOffice and OpenOffice, so a document in those formats can be checked without conversion.
- First install step
- Full setup guide
#!/usr/bin/env sh curl -L https://raw.githubusercontent.com/languagetool-org/languagetool/master/install.sh | sudo bash $options
textlint/textlinttextlint is the pluggable linter for natural language text.
- Best for
- A documentation team that wants the ESLint model applied to prose, so the rule set is chosen, pinned and reviewed like code in a repository.
- What you give up
- It has no bundled rules, so a fresh install reports nothing until you assemble and pin rule packages yourself. A global install with local rules reports nothing either, because textlint and the rules must resolve from the same node_modules, and the fix mode rewrites files in place unless you pair it with the dry run switch.
- Moving from Grammarly
- Markdown and plain text are read as they are, so an existing documentation repository can be linted in place: point textlint at a directory of .md files and it picks up the .textlintrc.json configuration from the working directory.
- First install step
- Full setup guide
$ npm install textlint --save-dev
amperser/proselint[Mirror] A linter for prose.
- Best for
- A writer or a documentation repo that wants a small, opinionated set of style checks wired into a pre-commit hook, where every warning names the check that produced it.
- What you give up
- It is English only and it checks style rather than grammar: there is no language model, no sentence-level grammar rule set and no spell checker beyond what the catalogue defines. The checks are opinionated by design, drawing on a specific set of writers and magazines, so a team has to disable the ones it disagrees with. The canonical home has moved to codeberg.org, and the GitHub repository describes itself as a mirror.
- Moving from Grammarly
- Plain Markdown files are checked in place: proselint check on a .md file prints one line per suggestion in the form file:line:column: check_name: message, and the JSON output format is stable enough to build a wrapper on.
- First install step
- Full setup guide
pip install proselint
Smaug6739/Alexandrie📚 The open-source, offline-first Notion, Obsidian & Confluence alternative. Advanced Markdown, multi-tenant teams, OIDC/SSO, and local S3 backups. Deploy in one command.
- Best for
- A team that wants a self-hosted Markdown wiki with per-node permissions, an offline-capable web app and its own object storage, and that would rather run the prose checks in CI than in the editor.
- What you give up
- It has no grammar or style checker at all, so the checking half of the job is not covered. The quick start copies an example environment file whose credentials already work in the repository, only the database image is pinned while the object store and the backend track a floating tag, and the database and the object store are published on host ports.
- Moving from Grammarly
- Markdown documents move in and out through the ZIP import and export tools, which restore selected nodes, metadata configuration or a whole platform state in a single action.
- First install step
- Full setup guide
# 1. Download the .env.example and docker-compose.yml files curl -O https://raw.githubusercontent.com/Smaug6739/Alexandrie/main/.env.example curl -O https://raw.githubusercontent.com/Smaug6739/Alexandrie/main/docker-compose.yml # 2. Configure environments cp .env.example .env # 3. Launch the stack docker compose up -d
What a hosted checker does for you, and what you take back
Grammarly is a hosted writing assistant that checks spelling, grammar and style in a document and suggests rewrites, through a browser extension and an editor integration. Three things follow from that description. The text you write is sent to the vendor's servers to be checked, so the document has to leave your machine to be proofread. The suggestion engine is the vendor's, and the rules it applies are not yours to change. And the browser extension needs the service to be reachable, so checking stops when it is not.
The four candidates below all move that work onto your own hardware. The trade is straightforward on the privacy side: your documents never leave the machine, and the rule set becomes a file you can fork, pin and argue about in review. The other cost is that you now own the client. Every project below is a server, a command line tool or an application, and none of them is the extension that marks a sentence in whatever web app you happen to be typing in.
Three of the four are checkers in different senses. The fourth is not a checker at all, and it is on the list for a reason worth stating plainly: teams that own their documents often want the linting to run in continuous integration, and they need somewhere to keep the documents first.
A language engine, a runner, a catalogue of checks, and a wiki
languagetool-org/languagetool is a Java proofreading engine. It covers English, Spanish, French, German, Portuguese, Polish, Dutch and more than 20 other languages, it finds errors a simple spell checker cannot detect, and it exposes an HTTP API, a Java API and a server mode. The rules live inside the project, so the coverage is what the project ships rather than what you assemble. The price is the runtime: Java 17 and Apache Maven to build from source, and a clone that wants a lot of disk.
textlint/textlint is the opposite design. The engine ships with no rules at all. Rules arrive as npm packages such as textlint-rule-no-todo, and the .textlintrc.json file decides which ones run and how each is configured. Markdown and plain text are read directly, and HTML needs a processor plugin. The rule catalogue is therefore the value and textlint is the runner. That is a good design for a team that wants its writing rules reviewed like code in version control, and a poor one for anyone who expects the check to work on the first run.
amperser/proselint sits between the two. It is a Python package with a fixed catalogue of checks drawn from a specific set of writers and magazines. Every warning names the check that produced it, the JSON output format is stable enough to build a wrapper on, and a pre-commit configuration pins a tag, so a team can adopt it in a single commit.
Smaug6739/Alexandrie is the odd one out. It is a self-hosted Markdown knowledge base with an extended CodeMirror editor, an offline-capable web app, a five-level permission model, OpenID Connect providers and S3 compatible storage. It checks nothing. What it offers is the place where the documents live.
Choosing by situation: a writer, a documentation team, a company with rules, a developer embedding checks
A writer who needs grammar checked in a language other than English has one real option on this page: languagetool-org/languagetool. Nothing else here looks at grammar, and LanguageTool is the only candidate with a rule set per language. The cost is a JVM and a service to keep alive.
A documentation team that already keeps its prose in a repository and reviews it like code should look at textlint/textlint, with amperser/proselint as the lighter alternative when style rules are enough. textlint lets you pin each rule package and configure it in .textlintrc.json; proselint gives you a smaller catalogue that either matches your style guide or does not.
A company with retention, residency or audit requirements can run any of the three checkers on its own infrastructure, and that is often the whole reason for the move. What changes is who decides. With a hosted service, a rule change is the vendor's decision and arrives without a review. With LanguageTool or textlint, a rule change is a pull request somebody reviews.
A developer embedding checking into a product has a different list again. LanguageTool gives an HTTP API, the cleanest interface to call from an editor or a service. textlint gives a command line that reports on files and can rewrite them. proselint gives a command line and a JSON format. All three assume you build the surface your users actually see, which is the part the hosted product was doing for you.
What each one costs to keep running
languagetool-org/languagetool is the heaviest to build and among the lightest to run once built. The installer offers standalone, wikipedia and office-extension packages, and the build path needs Java 17 and Apache Maven. The README warns that a complete clone downloads more than 500 MiB and needs more than 1 500 MiB on disk, and that a shallow clone of depth five brings that down to less than 60 MiB and less than 200 MiB of disk. The Docker route exists, but the images listed in the README come from community-contributed projects, so you are trusting somebody else's build rather than the maintainers'.
textlint/textlint is a Node.js tool that stays in the repository. The install is npm install textlint --save-dev on Node.js 20 or newer, the rules are npm packages installed beside it, and a run is npx textlint with a glob. No server to run, no database to keep. The operational risk is a quiet one: a global install with local rules silently reports nothing, and the fix mode rewrites files in place unless you add the dry run switch and look at the diff first.
amperser/proselint is a Python package with no service at all. pip install proselint, or a distribution package, or a nixpkgs entry, and the pre-commit hook is a short block that pins a tag. Its cost is editorial rather than operational: the checks are opinionated by design, the version that matters is v0.16.0 from November 2025, and the last commit reached the GitHub mirror on 2026-09-04.
Smaug6739/Alexandrie is a service, not a tool. Its quick start is a compose file with a database, an object store and the backend, brought up in three commands, and it publishes the database and the object store on host ports, so firewall rules are part of the installation. The permission model, the OpenID Connect providers and the automated backup and restore pipelines are the parts that need a real owner.
Licence conditions, and where each one is the weaker choice
languagetool-org/languagetool is LGPL-2.1, and that is a condition a company has to read rather than skim. The core is freely available under that licence, and the part that bites is distribution: running the server on your own machines raises no obligation to publish your changes, but shipping a modified build means publishing them.
textlint/textlint is MIT and amperser/proselint is BSD-3-Clause, so both can go into a commercial product with no obligation beyond keeping the licence text.
Smaug6739/Alexandrie is MIT as well, but the licence is the smaller problem there. Its own documentation notes that the compose file ships default credentials for every service, that only the database image is pinned while the object store and the backend track a floating tag, and that one object storage target binds every network interface with a hardcoded secret. A team that exposes this to staff has to change those values before the first user arrives.
Where each one is the weaker choice: proselint for anyone who wants grammar, textlint for anyone who will not build a rule set, LanguageTool for anyone who will not run a JVM, and Alexandrie for anyone who wanted a writing checker and found a wiki instead. The choice is less about the tools than about how much of the checking surface you are willing to own.
Bottom line
A team that needs grammar in languages other than English should start with languagetool-org/languagetool, a documentation repository that wants its rules pinned in version control should start with textlint/textlint, and a writer who only wants a style pass should start with amperser/proselint. Before committing, check the language coverage you actually need, run the checker against your own worst document, and confirm that the editor, browser or CI job you use can call the tool you picked.