LanguageTool: self-hosted grammar checking with a Java server and a plain HTTP API

The gap LanguageTool fills: errors a spell checker cannot see

A spell checker answers one question: is this token a word? LanguageTool answers a different one. The README states it "finds many errors that a simple spell checker cannot detect," which is the whole reason the project exists. That means agreement errors, wrong-word substitutions, and style patterns, not just typos. The target user is not a novelist looking for a nicer adjective. It is an engineer or a team that needs proofreading inside a pipeline, an editor, or an internal tool, and needs it in a language other than English. The README lists English, Spanish, French, German, Portuguese, Polish and Dutch explicitly, then points to more than 20 others on the languages page. That breadth is the differentiator. Most checkers of this class are strong in English and thin elsewhere; LanguageTool's rule sets are split into per-language modules under languagetool-language-modules, and German in particular is a language people search for by name. The second differentiator is deployment. The core is available under LGPL 2.1 or later, so you can run the checker on your own machine, in your own network, without sending text to a third party. For anyone handling contracts, medical notes, or unreleased source code, that is not a nice-to-have.

How the engine is put together: core, language modules, server, clients

The repository layout makes the architecture legible without reading a design document. languagetool-core holds the checking engine. languagetool-language-modules holds the per-language rule and dictionary data, which is why a build pulls so much: the rules ship with the code. languagetool-server wraps the core in an HTTP service. languagetool-commandline is the batch entry point, languagetool-gui-commons backs a desktop interface, languagetool-office-extension is the LibreOffice and OpenOffice add-on, and languagetool-wikipedia is a separate packaging aimed at wiki text. There are also languagetool-http-client and languagetool-client-example, so you can call a running server from Java without hand-rolling requests. The data flow is conventional: a client sends text to the server, the server runs the text through the core with the rules for the detected or requested language, and returns a list of matches with offsets, a message, and a suggested replacement. The README links the HTTP API documentation as a Swagger UI page and a separate Java API page with Javadoc for JLanguageTool. That split matters operationally. If you only need checking, the server plus HTTP is enough and you never touch the Java API. If you are embedding the engine in a JVM application, languagetool-core is the dependency and no server is involved.

Installing LanguageTool with install.sh and running a first check

The README offers a scripted path. The one-liner downloads install.sh from the master branch and pipes it into sudo bash, so read the script before running it, since the flags include accepting the Oracle Java license. After installation, the script can launch a GUI, a command-line check, or a server, chosen with the -c flag. The default is gui when a screen is detected.

#!/usr/bin/env sh
curl -L https://raw.githubusercontent.com/languagetool-org/languagetool/master/install.sh | sudo bash $options

The same script accepts options when downloaded and run directly. This runs the server after installing, which is the mode you want for an API:

sudo bash install.sh -c server

For a build from source, the README requires Java 17 and Apache Maven. A full clone is large, so the shallow form is the practical one:

git clone --depth 5 https://github.com/languagetool-org/languagetool.git

Then, from the root project folder, compile and test, and package the standalone distribution:

mvn clean test
./build.sh languagetool-standalone package -DskipTests

The README says to test the result in languagetool-standalone/target/. The build script also packages languagetool-wikipedia, with output in languagetool-wikipedia/target. Note the warning attached to source builds: the README calls the result a "bleeding edge development copy" that "might contain regressions." That is a fair description of master. If you want a stable artifact, use a tagged release rather than a master build.

Docker is community-maintained, not part of the core repository

This is the detail most deployment guides get wrong. The README does not ship a Dockerfile. It points to three community projects instead: meyayl/docker-languagetool published as meyay/languagetool on Docker Hub, Erikvl87/docker-languagetool published as erikvl87/languagetool, and silvio/docker-languagetool published as silviof/languagetool. The README explicitly calls these "community-contributed." The consequence is concrete. Their image tags, base images, exposed ports and upgrade cadence are set by their maintainers, not by the LanguageTool project, and nothing in this repository guarantees they track the core. If you deploy one of these images, you own the question of which LanguageTool version is inside it, and you should verify that yourself. The upside is real: a container avoids the Java 17 and Maven setup entirely, and for a service you want to restart on demand, that is usually the right trade. The cost is that your supply chain now has a second maintainer in it.

Where LanguageTool is the wrong tool

The build cost is the first honest limitation. The README states that a complete clone requires more than 500 MiB of download and more than 1500 MiB on disk. The shallow clone reduces that to under 60 MiB and under 200 MiB, so the constraint is manageable, but it tells you what the project is: a rule corpus, not a small library. The second limitation is rule quality variance. Because coverage is split across language modules, the experience is not uniform across the 25+ languages. A rule set that is mature for German or English may be sparse for a language with fewer contributors, and the README does not publish per-language accuracy figures. If your language is not one of the seven named in the README, verify coverage on real text before you plan around it. The third limitation is that the core is a checker, not an editor. It returns matches; it does not rewrite a document, manage style guides per team, or integrate with a writing workflow on its own. Everything above the match list is your code. Finally, the README does not document rollback for install.sh beyond a -r flag that removes the install, with all also uninstalling auto-installed dependencies. If you need a clean, scripted uninstall, that flag is the only documented path.

LanguageTool against Grammarly and the hosted-checker model

The comparison people search for is LanguageTool versus Grammarly, and the difference is architectural rather than a matter of which catches more commas. Grammarly is a hosted product. Your text leaves your machine, the model lives with the vendor, and pricing, language support and feature set are set by that vendor. LanguageTool's core is LGPL-2.1 software you can run yourself, including offline, which is why "LanguageTool offline" is a recurring search. The trade runs both ways. Self-hosting means you carry the JVM, the disk footprint, the rule updates and the server operation. It also means no per-seat billing and no text leaving your network. The other category worth naming is the Python wrapper ecosystem, which people find by searching for language_tool_python. That is a client library for talking to a LanguageTool server, not a reimplementation of the checker, so it inherits whatever server you point it at. Whichever route you take, the engine underneath is the same Java code in this repository.

License, upgrade cost and what the LGPL-2.1 core implies

The README states that the LanguageTool core is distributed under the LGPL 2.1 or later, with COPYING.txt at the repository root. The README also qualifies this with "unless otherwise noted," which is a signal that not every file in the tree necessarily carries the same terms. If you plan to redistribute a modified build, read COPYING.txt and the headers on the files you touch rather than assuming the whole tree is uniform. This is not legal advice; it is a pointer to where the answer lives. On upgrades, the repository gives you the mechanics and not a schedule. build.sh, build-zip.sh, create_snapshot.sh, deploy_release.sh and do_release.sh are all present at the top level, and CHANGES.md is linked from the README for release history. The maintenance cost you should budget for is the rebuild loop: a Java 17 toolchain, Maven, and a package step every time you want a newer rule set. Teams that pin a version and rebuild quarterly will find that cheap. Teams that expect the server to update itself will not find that here.

Editorial conclusion

Adopt LanguageTool when you need grammar checking to run on your own hardware, in a language other than English, or behind an HTTP API you control; the LGPL-2.1 core and the server module make that possible without a commercial agreement. Skip it if you want a managed service with no JVM, no 500 MiB clone and no rule-tuning, because none of that is in this repository. Before committing, clone shallow, run mvn clean test, start the server, and confirm your target language has the coverage you expect.

Frequently asked questions

Official sources

1. Issues
2. languagetool-org/languagetool on GitHub
3. License: LGPL-2.1
4. Project website
5. README