Which Languages and Scripts Can HTR Read? A Guide to HTR Supported Languages

This is a guide to HTR supported languages — and to why a language count is the wrong place to start. Handwritten text recognition is governed first by script, then by language, then by the specific hand on the page. Understanding that order will tell you whether a tool can actually read your material, and save you weeks of misdirected effort.

Handwritten text recognition is defined first by script, not by language. An HTR engine reads the visual repertoire of glyphs on the page — the Latin alphabet, Cyrillic, Arabic, Hebrew, Devanagari, Han — and any language recorded in a script the engine can read is, in principle, within reach. So the honest answer to "which languages can HTR read?" is that it depends on whether a trained model exists for the specific combination of script, language, and hand in front of you. Coverage is uneven, community-built, and growing rather than a fixed vendor list. That distinction is the whole subject, and getting it right will save you weeks of misdirected effort.

Script versus language: the distinction that governs everything

A script (or writing system) is the set of glyph shapes used to encode text. A language is a linguistic system mapped onto that repertoire. The two are not the same axis, and they do not vary together.

The Latin alphabet alone carries English, French, German, Dutch, Spanish, Italian, Portuguese, Polish, Czech, Turkish, Vietnamese, and dozens more. The reverse also holds: a single language can be written in more than one script — Serbian appears in both Latin and Cyrillic. When a tool advertises "100+ languages supported," it is compressing a more complicated reality into a marketing figure. What actually determines whether you get a usable transcription is narrower and more specific than a language count.

This is the same distinction that separates HTR from OCR: both combine a visual model over the image with an optional language model that biases output toward plausible words, but HTR must generalize across the far greater shape variability of connected, cursive handwriting. The visual model handles the script. The language model handles the lexicon. Confuse the two and you will ask the wrong question of your tool.

What "supported" actually means

In practice, "support" collapses into four things that marketing routinely conflates:

1. Engine capability — the underlying system can process the script at all.
2. A ready model — a trained, ready-to-use model exists for that script, language, and hand.
3. Trainability — you can train your own model on the engine, given ground-truth data.
4. Community catalogues — someone has already trained and published such a model.

These are different claims. An engine may be capable of a script while no ready model exists for your particular hand. Transkribus, for instance, markets 100+ languages and 150+ public models across 75+ languages through a marketplace of community-contributed models — a genuine strength, and also an illustration of the point: the coverage is a catalogue, not a guarantee, and its density varies widely by language and period. eScriptorium, built on the Kraken engine — which is optimized for historical and non-Latin material — ships no fixed "supported languages" list at all. You train per-corpus models. That is not a weakness so much as an honest reflection of how the field works.

The Latin-script family: where transfer helps

The most persistent misconception is that if a tool reads English handwriting, it cannot read French or German without starting from scratch. It is not true, and the reason is structural: within the Latin-script family the alphabet overlaps heavily, and the visual character shapes are largely shared. A model trained on one Latin-script language often transfers to a related one with only modest accuracy degradation. Transkribus markets exactly this with a generalized Latin-script model; multilingual transformer approaches such as TrOCR apply the same principle.

Transfer is strongest among closely related languages — English and French, Italian and Spanish — and degrades for more distant ones, or for languages carrying extensive diacritics such as Czech or Vietnamese, where the accents themselves become recognition targets the model may not have learned. So the practical rule is this: within Latin script, breadth across languages is often achievable from a single well-trained model, but you should expect the margin to widen the further you move from the training material.

This is also where a common naming trap lives. In OCR and Tesseract language packs, "Latin" refers to the Latin language, not the Latin script. A tool that lists "Latin" in its pack may still handle a medieval Latin manuscript in Caroline minuscule or textualis poorly — because that is a hand recognition problem, not a language-coverage problem. The question is never "does it do Latin?" It is always: script, then language, then hand.

The variable that undoes language lists: the hand

Once you accept that script comes first, the next reality is that the specific hand or typeface often matters more than the language. Historical writing and printing styles within the Latin script — secretary hand (English, 1500s to mid-1600s), court hand, Kurrent and Sütterlin (German, roughly the 1500s to the 1940s), italic, and Fraktur/blackletter — each impose their own visual conventions. Secretary hand, Kurrent, and Sütterlin in particular require hand-specific or typeface-specific models even when the underlying language is thoroughly supported. A German-language model trained on modern print will not read Kurrent; the language is the same, the hand is not.

This is why reported accuracy figures are only meaningful against a stated hand and dataset. A dedicated model like Transkribus's Egerton English Secretary Hand model reports 2.89% character error rate on its own validation set — a good result, and one that tells you nothing about how the same engine performs on a Dutch notarial hand or a degraded eighteenth-century ledger. CER and word error rate are edit-distance measures normalized by reference length; CER dominates in HTR because word boundaries are unreliable in cursive. The conventional interpretation bands — roughly 1–2% good, 2–10% average to good, above 10% poor — are widely cited but dataset-specific. Cross-tool CER comparisons without a matched test set, identical preprocessing, and consistent protocol are unreliable, and you should treat any single headline number with the caution that qualifier deserves. Understanding how those numbers are produced is worth the detour into how an HTR pipeline actually works, from segmentation through recognition to export.

Non-Latin scripts: the deeper coverage problem

Beyond the Latin family, the terrain changes. Arabic, Hebrew, Greek, Cyrillic, Devanagari, and Han are scripts, not languages — and each covers many languages. Arabic script carries Arabic, Persian, Urdu, and Pashto; Cyrillic carries Russian, Ukrainian, Bulgarian, and Serbian; Devanagari carries Hindi, Sanskrit, and Marathi. The right unit of analysis remains script plus language plus hand.

The engines exist. Kraken explicitly supports right-to-left, bidirectional, and top-to-bottom scripts. Specialist models report real results — a Russian-language Transkribus model at roughly 2.4% CER, and the HATFormer Arabic system reporting 8.6% and 4.2% CER on two datasets. But published evidence for non-Latin scripts remains thinner than for Latin, and the standard benchmark competitions (ICDAR, ICFHR; Bentham, IAM, RIMES) are predominantly Latin- or Arabic-script. If your material is Cyrillic, Arabic, or an Indic or East Asian script, expect a smaller catalogue of ready models and a greater likelihood that you will need to train your own.

What conventional OCR does — and where it stops

General-purpose cloud OCR advertises broad language coverage. Google Cloud Vision detects many languages; ABBYY FineReader lists 190-plus for print; Tesseract ships around 100 via downloadable traineddata files. These systems are genuinely good at what they were engineered for: clean, modern, high-contrast type, receipts, forms, born-digital PDFs. Fast, cheap, accurate.

Their accuracy drops materially on two things a language list does not warn you about: handwriting, and historical print. Fraktur and blackletter, the long s read as f, ligatures split or dropped, uneven inking and show-through read as spurious characters, and archaic orthography "corrected" by a modern language model — these break the assumptions a glyph classifier is built on. A language count of 190 tells you nothing about whether a tool can read a 1580 blackletter pamphlet. That gap is the reason the distinction between HTR and OCR matters in the first place, and why dedicated historical-print programmes such as OCR-D and IMPACT exist at all.

Reading Latin-script material without training a model

Most of this guide points toward a single practical conclusion: the useful question is not "how many languages," but "is there a ready model for my script, language, and hand — and if not, am I prepared to build one?" For a great deal of specialist HTR, the honest answer to that second half is that you will be training or fine-tuning per corpus.

This is the stage where Leo is built to help, and where it takes a deliberate position. Its transcription model, ATR-1, is zero-shot across the Latin-script family: it reads handwritten and printed material in the Latin alphabet from roughly the past five centuries — English, French, German, Dutch, Spanish, Italian, Latin among them — without asking you to train a model first. The scope is defined by the writing system, not the language on the page; the typical user is working in vernacular records — English wills, French notarial minutes, Dutch registers, German parish books — far more often than in Latin. On a randomized 97-image sample of early-modern English manuscripts from the Folger Shakespeare Library, ATR-1 recorded roughly 5% CER at release — about 61% fewer errors than the next-best model tested, with the full comparison published here. As with any such figure, it is a single corpus and a single hand; it describes that material, not a universal guarantee.

The constraint is the one this guide has been circling: ATR-1 reads Latin script only. Greek, Cyrillic, Hebrew, Arabic, and Indic or East Asian material is out of scope. Where it earns its place is in the source integrity that historical work demands — it transcribes what is on the page, preserving strikethroughs, marginalia, expansions, and archaic spelling rather than smoothing them into modern, plausible prose. That matters because the dangerous errors in this field are not the visibly garbled ones but the fluent fabrications a general chatbot produces, which read as correct and are hard to catch. Leo's flagship public corpus, ExLatinis, happens to be Latin-language — one collection among the many languages the same model reads, not the boundary of what it is for.

The practical test

When a tool tells you how many languages it supports, treat the number as the beginning of the question, not the answer. Ask instead: Can the engine read my script? Is there a ready model for my language within that script — or one close enough to transfer? And does a model exist for my specific hand or typeface, or will I need to build one? Then check the conditions that undo even good coverage: a new period, a degraded scan, heavy abbreviation, code-switching across a page, dense tables and marginalia. HTR is not solved. Clean modern handwriting can reach very high accuracy; cursive, historical, and non-Latin hands remain variable, and every benchmark is specific to the material it was measured on. The scholars who get reliable results are the ones who match the tool to the page in front of them — and who read the output against the source, every time.

Frequently Asked Questions

What languages does HTR support?

HTR support depends first on script, then language, then the specific hand — not on a headline language count. Any language written in a script the engine can read is, in principle, within reach: the Latin alphabet alone carries English, French, German, Dutch, Spanish, Italian, and dozens more. But usable transcription requires a trained model for your specific combination of script, language, and hand. Coverage is uneven, community-built, and growing rather than a fixed vendor list. When a tool advertises "100+ languages," treat that number as the start of the question, not the answer.

What is the difference between a script and a language in HTR?

A script is the set of glyph shapes used to encode text — the Latin alphabet, Cyrillic, Arabic, Hebrew, Devanagari, Han. A language is a linguistic system mapped onto that repertoire. The two are separate axes: the Latin alphabet carries English, French, German, and dozens of others, while a single language like Serbian can be written in both Latin and Cyrillic. In HTR, the visual model handles the script and the language model handles the lexicon. This distinction governs everything, because it determines whether a tool can read your material at all.

Can an HTR model trained on English read French or German?

Often, yes — within the Latin-script family a model trained on one language frequently transfers to a related one with only modest accuracy loss, because the alphabet overlaps heavily and the visual character shapes are largely shared. Transfer is strongest between closely related languages like English and French, or Italian and Spanish. It degrades for more distant languages, and for those carrying extensive diacritics such as Czech or Vietnamese, where the accents become recognition targets the model may not have learned. Expect the margin to widen the further you move from the training material.

Why does handwriting style matter more than the language?

Because the specific hand or typeface imposes its own visual conventions that a language-trained model may never have seen. Secretary hand, court hand, Kurrent and Sütterlin, italic, and Fraktur or blackletter each require hand-specific models even when the underlying language is thoroughly supported. A German model trained on modern print will not read Kurrent — the language is identical, the hand is not. This is also why reported accuracy figures only mean something against a stated hand and dataset; a strong result on one hand tells you nothing about performance on a different notarial hand or a degraded ledger.

Can HTR read Cyrillic, Arabic, or Indic scripts?

The engines can — Kraken supports right-to-left, bidirectional, and top-to-bottom scripts, and specialist models report real results, including a Russian Transkribus model around 2.4% CER and an Arabic system reporting 8.6% and 4.2% CER on two datasets. But published evidence for non-Latin scripts is thinner than for Latin, and the standard benchmark competitions are predominantly Latin- or Arabic-script. If your material is Cyrillic, Arabic, or an Indic or East Asian script, expect a smaller catalogue of ready models and a greater likelihood that you will need to train your own.