If you've searched for a "LanguageTool API," you've probably found the same three things everyone finds: a public endpoint with a 20-requests-per-minute cap, a Java server you can download and run yourself, and a premium tier that still doesn't feel like a developer product. All three are real. None of them is obviously the right answer for a product team that needs grammar corrections returned as structured data.
This guide walks through all three options honestly — what each one actually costs in production, where the hidden limits are, and when a managed proofreading API is the better call. We build AmberPen, a managed proofreading API, so we have an obvious stake here. We also benchmark every engine we can get our hands on and publish the results, so we'll keep the numbers on the table.
The three LanguageTool APIs
1. The public endpoint. LanguageTool runs a free, shared HTTP API at languagetool.org/api/v2/check. It's genuinely useful for a demo or a side project. The production limits are the catch:
- 20 requests per minute per IP address
- 75,000 characters per day per IP
- No SLA, no uptime guarantee, and a polite note that the endpoint is "not for production use"
For a product with real users, 20 req/min is the hard ceiling. A single busy editor tab can burn through that in a burst.
2. The self-hosted server. Download the LanguageTool JAR, run it on your own VM, and point your app at localhost:8081/v2/check. No rate limits, no per-request cost, and your text never leaves your network. This is the option that makes "LanguageTool API" searches spike — it feels like the best of both worlds.
3. The premium tier. LanguageTool's paid plans lift the public-endpoint limits and add a few style rules, but the product is still aimed at individual writers, not at applications. There's no per-request pricing, no usage dashboard, and no API key management designed for a backend service.
The hidden costs of self-hosting
Self-hosting is the right answer for a specific set of constraints — air-gapped networks, regulated data, or extreme volume with a modest quality bar. For everyone else, the invoice arrives in three parts.
The JVM is the easy part. A LanguageTool server wants several gigabytes of heap, the n-gram dataset on disk for confusion-pair detection, a process supervisor, TLS, and enough headroom for peak load. A comfortable VM runs $40–$100 per month at a major cloud. That's the number people quote when they say self-hosting is nearly free.
The wrapper is the real work. The server gives you a raw HTTP endpoint. You still need authentication, rate limiting, request validation, monitoring, and a rollback plan for when a new LanguageTool release changes behavior. A new rule can flood your UI with false positives; somebody has to notice, diff the behavior, and roll back. That somebody is an engineer on your team, forever.
The quality ceiling is the part you can't engineer around. LanguageTool is rule-based at its core. Rules are precise and fast for the patterns they encode, but an error that no rule anticipates is invisible. When we ran public benchmarks over identical inputs (methodology on the benchmarks page), LanguageTool found 18.3% of the errors human annotators marked in real web text, at 37.8% precision. A neural API found roughly two-thirds at similar precision. The AmberPen vs LanguageTool comparison lists five ordinary contextual errors — "He poured over the documents," a dangling modifier, present perfect with a past time — that a live LanguageTool server reported as perfectly fine.
If your users mostly make mechanical mistakes (its/it's, their/there, "could of"), the ceiling may never matter. If they write real prose, it will.
What a managed proofreading API adds
The difference isn't just "someone else runs the server." A managed API is built for the integration pattern a product actually needs:
| Concern | Self-hosted LanguageTool | Managed proofreading API |
|---|---|---|
| Rate limits | Your own ops problem | Handled by the service |
| Custom vocabulary | Server-side config files | Per-request dictionary and properNouns fields |
| Edit format | Matches with offsets and replacements | Structured edits with UTF-16 offsets, explanations, and categories |
| Streaming | Not supported | Complete edit batches as NDJSON |
| Incremental checking | Not supported | SDK diffs the document and sends only changed chunks |
| Quality ceiling | Rule-based (18.3% recall on CWEB) | Neural (65.5% recall on the same corpus) |
| Cost at moderate volume | VM + engineer time | €5/month with 500K characters included, then €9 per million |
The edit-format row deserves emphasis. LanguageTool returns a list of matches — each with an offset, a length, and a list of possible replacements. A managed API like AmberPen returns a sorted, non-overlapping list of edits that transform the submitted text into the corrected text, with start/end in UTF-16 code units you can pass directly to String.prototype.slice. That's the difference between rendering raw flags and building a suggestion UI.
When each option wins
Use the public endpoint for a hackathon, a demo, or a low-traffic personal tool. Respect the 20 req/min cap and don't build a business on it.
Self-host LanguageTool when data locality is mandatory, when you're offline-first, or when volume is extreme and quality expectations are calibrated to rule-based checking. It's also the right choice for a student project or a community tool with zero budget.
Use a managed API when correction quality is part of your product's promise, when your team is small, when you need streaming or incremental checking, or when you'd rather meter by character than staff a service. At moderate volumes the math is short: a €5 Starter plan costs less than the VM you'd run for LanguageTool, before counting a single hour of the engineer babysitting it.
The honest middle ground
There's a real third path that doesn't fit neatly into the table above: use both. Some products run LanguageTool for the languages it covers well (German, French, Spanish) and a neural API for English, where contextual errors are the ones users notice. Others use LanguageTool as a fast first pass and escalate uncertain sentences to a managed API. The grammar checker API comparison covers the managed options alongside the self-hosted ones, and what you'll actually pay models the billing math across per-character, per-token, and per-seat plans.
If you're weighing the self-hosted route specifically, the true cost of self-hosting a grammar checker prices the quality ceiling, the ops burden, and the engineering time in more detail. And if you want to see the managed side before committing to anything, a free test key returns real corrections in about two minutes — no credit card, no sales call.
The worst outcome is the accidental middle: three months building around a self-hosted checker, only to discover the recall ceiling after users stop trusting the underlines. Avoid it by testing quality first — run your own representative texts through both options. Our benchmark methodology is public, the corpora are public, and the comparison is free to reproduce.