Handwritten Text Recognition: A Practical Guide to Reading Historical Documents with AI

This is an introduction to handwritten text recognition (HTR) for anyone meeting the term for the first time — what it is, how it differs from OCR, and how to fit machine transcription into serious work on historical documents. It matters because a tool that reads a page for you can also quietly rewrite your sources, and knowing where the line falls is the difference between a first draft you can trust and one you cannot.

Handwritten text recognition is the automated transcription of handwriting from page images into machine-readable text. It differs from optical character recognition (OCR) in a way that matters. OCR classifies printed glyphs one at a time; HTR reads a whole line of connected script in context, because cursive has no reliable letter boundaries to segment. Modern HTR uses sequence models — recurrent networks, then attention, now transformers — trained on real handwriting rather than typefaces. On difficult historical hands it works well enough to be useful. But it is not solved: even strong models leave errors a reader must check against the page.

That last sentence is the one most guides skip, and it is the one that should govern how you use the technology. This piece explains what HTR is, why it exists as a field distinct from OCR, how to read the accuracy numbers you will encounter, and how to fit machine transcription into serious work without letting it rewrite your sources. It sits under our broader guide to handwritten text recognition as an entry point for readers meeting the term for the first time.

Why OCR cannot read old handwriting

The persistent misconception is that OCR and HTR are the same tool wearing different names. They are not, and the difference is mechanical.

OCR was engineered for machine-printed text. Print gives it reliable glyph boundaries, consistent baselines, even spacing, and a small, known set of typefaces. The classic pipeline moves page → line → word → glyph, then classifies each glyph against that expectation. On a clean modern page it is fast, cheap, and very accurate — good OCR runs at a 1–2% character error rate.

Handwriting breaks every assumption in that pipeline. Cursive connects letters, so there are no clean glyph boundaries to find. Layouts are irregular. The same scribe writes the same letter three ways on one line. So HTR abandons per-glyph classification entirely. It treats a whole text line as one image and maps it to a sequence of characters, using sequence models that read the line in context — the way a reader infers an ambiguous letter from the word around it. Transkribus, whose engine popularized the approach for archives, puts the distinction plainly: HTR is trained on real handwriting samples rather than typefaces.

There is a subtlety worth holding onto, because it will save you from a category error later. The line between "print" and "handwriting" is not the line between "easy" and "hard." Historical print is often as hard as handwriting for conventional OCR: early-modern founts, blackletter and Fraktur, the long s (ſ) that OCR reads as an f, ligatures that split or vanish, and the macron standing in for an omitted nasal. Berkeley's 2024 test of a nineteenth-century document found ABBYY FineReader misreading roughly half the city names on a table, and long-s-to-f is the single most common Fraktur error. The right dividing line is not print versus handwriting. It is modern and regular versus historical and irregular — and the second category is what a purpose-built model has to be trained for, whether the marks were made by a press or a pen.

Script, language, and hand: what "supported" actually means

Ask "can HTR read my documents?" and the honest answer has three parts, not one.

Script

Script is the writing system — the alphabet family. Most historical HTR tooling is built for the Latin script: the alphabet used to write English, French, German, Dutch, Spanish, Italian, Portuguese, Polish, and dozens of other languages, including Latin itself. Non-Latin scripts — Greek, Cyrillic, Hebrew, Arabic, and the Indic and East Asian systems — are a genuinely different problem, and support for them lags the Latin-script tooling by years. A vendor claim of "100+ languages" is really a claim about script coverage plus language priors. It does not mean every hand in every language reads equally well.

Language

Language shapes the priors a model brings to ambiguous marks, and coverage is uneven. Published benchmarks over-represent English. Peer-reviewed evaluation is thinner on German Kurrent and Sütterlin, French notarial hands, and Spanish and Italian cursive. A model strong on English can be mediocre on a German parish register.

Hand

Hand is the individual style of script — secretary hand, court hand, italic, Kurrent. This is often the real determinant of success, and the one most easily hidden by a headline figure. Our guide to which languages and scripts HTR can read works through why the honest unit of support is script + language + hand together, not a language count.

How to read an accuracy number

HTR quality is reported as character error rate (CER): the proportion of characters wrong through insertion, deletion, or substitution, borrowed from speech recognition. A perfect transcription is 0% CER. On difficult historical material, anything under about 10% is respectable, and figures above that are not unusual. Word error rate (WER) does the same at the word level and always runs higher, because a single wrong character spoils a whole word.

The trap is treating one number as a property of a tool. It is not. Published CERs are almost impossible to compare across studies, because they come from different datasets, different evaluation protocols (strict versus lenient), different page splits, and different amounts of language-model post-processing. Romein and colleagues demonstrated this directly in their Sugar Loaf Test: the ranking of HTR engines shifts depending on the dataset. A model that wins on one collection loses on another. And the field's own competition organizers were blunt in 2024 that HTR performance remains far from satisfactory on the hardest material.

Two practical consequences follow. First, a CER measured on someone else's collection tells you little about yours; the only number that matters is the one you measure on a sample of your own hands. Second, decide your tolerance before you start. Roughly 5% CER is publishable-quality first-pass text; 15% is usually still good enough to make a collection searchable but not to quote from without close correction.

Trained models, zero-shot models, and the training-budget question

For years, using HTR meant training a model. You transcribed a few thousand words of ground truth in a page editor, aligned it line by line, and built a model specific to your hand and genre. Transkribus still recommends around 10,000 words per hand for cursive to get good results. That is a serious investment before you transcribe a single page you actually care about, and it remains the right path for a large, homogeneous collection in an unusual hand.

The alternative is a zero-shot or foundation model: a general model pre-trained on a broad range of material that you can point at a page with no per-collection training. Transkribus's Text Titan I bis reports a vendor-measured 6.7% CER across Latin scripts out of the box; the open-source ARletta models do the equivalent for historic Dutch. "Zero-shot" means usable without fine-tuning — not that fine-tuning never helps, because for the hardest hands it still does. But for most researchers, most of the time, a good foundation model removes the training bottleneck.

This is the stage where the tool choice becomes real, and where our own model fits. Leo's ATR-1 is a zero-shot transformer model for Latin-script manuscripts and historical print — secretary hand, Gothic cursive, italic, and the founts conventional OCR mishandles — ready out of the box with no ground-truth step. On a randomized 97-image sample of early-modern English manuscripts from the Folger Shakespeare Library, at ATR-1's release, it recorded roughly a 5% character error rate — about 61% fewer errors than the next-best model tested (Transkribus/Text Titan I at ~13%, and the general LLMs Claude Opus, Gemini 2.5 Pro, and GPT-4.1 well behind); the full comparison and its per-model numbers are published here. That is one corpus in one language, which is exactly the caveat this article has been pressing: it is evidence about early-modern English hands, not a universal grade. What matters as much as the number is the design principle behind it — ATR-1 is built to transcribe what is on the page rather than to normalize it, so an archaic spelling, a strikethrough, or a macron survives into the output instead of being silently tidied away.

The "just paste it into ChatGPT" problem

The most common thing a newcomer reaches for is a general chatbot: photograph the page, upload it, ask for a transcription. It is worth understanding precisely why this is risky, because the failure mode is subtle.

General multimodal LLMs weight linguistic plausibility heavily and downsample the images you give them. On a difficult hand, that combination produces fluent errors rather than recoverable ones. A specialist HTR model that misreads tends to produce garble you can spot — a nonsense character, a broken word. A general LLM tends to produce a clean, confident, grammatical reading that happens to be wrong, and inserts plausible archaic spellings the source never contained. Evaluations of these pipelines document exactly this "over-historicization" and silent normalization. The best public study of the approach, a November 2024 preprint on Spanish notarial and ecclesiastical records, reached a strict 5.7% CER — but only by using one model to correct another's output, on a single collection, still requiring verification, and with the normalization problem intact. Trade-press claims that a new model has "solved" handwriting rest on demonstrations of a handful of pages, not benchmarks; as of this writing there is no ICDAR-style competition evaluating general LLMs on real archive material at scale.

The deeper issue is that a language model improves average word plausibility and can therefore overwrite a genuinely preserved archaic spelling or abbreviation — the double-edged role of language priors, with no agreed fix. Our longer treatments of why ChatGPT struggles on historical handwriting and of fluent-but-wrong LLM transcription errors work through the mechanism in detail. The short version: a wrong transcription that looks right is more dangerous than one that looks broken, because you will not think to check it.

Where crowdsourcing still wins — and where it doesn't

For decades the default for large backlogs has been human volunteers. It is highly accurate. The Smithsonian Transcription Center has run since 2013; climate-data-rescue projects reach about 99.5% accuracy on tens of thousands of weather values through replicate consensus; the Transcribe Bentham analysis found only around 1% of words needed staff alteration. Crowdsourcing produces excellent text.

What it cannot easily do is scale. It is bounded by volunteer supply, training, and reviewer fatigue — that same Bentham study clocked an average of 207 seconds of checking per transcript. Past a few tens of thousands of pages, recruitment becomes the constraint, which is why large projects increasingly run a hybrid: machine transcription for the first pass, human effort concentrated on verification and the hardest pages. That division of labor — machine reads, human checks — is the shape most serious HTR workflows now take.

Fitting HTR into real work

A defensible workflow treats machine transcription as a first draft, never a finished text. In practice that means a few disciplines.

Keep interpretation separate from the base transcription. The faithful reading of the page is one artifact; a modernized, translated, or corrected version is another, and conflating them corrupts your source. Verify against the image, not against the plausibility of the output — and prioritize the high-stakes tokens: names, dates, numbers, sums, and boundaries, where a single misread character does real damage. And keep your paleography sharp, because the skill that once read the page now verifies the machine; a model that hands you fluent output is precisely the one that needs a reader who can tell when it is fluently wrong.

Where HTR ends, other stages begin. Transcription sits after capture — after you have photographed the documents well enough to read — and before the metadata and publishing standards that make a collection findable and preservable. No single tool spans all of it, and a guide that tells you otherwise is selling something.

Handwritten text recognition has reached the point where it changes what a lone researcher or a small archive can attempt: collections that would have stayed unread in a lifetime of hand-transcription become searchable in weeks. But the technology reads; it does not understand, and it does not know when it is wrong. The judgment about what a document actually says — and what it means — still rests with the reader who knows the hand, the period, and the language. The machine gives you a faster first pass. The scholarship is still yours.

Frequently Asked Questions

What is handwritten text recognition and how is it different from OCR?

Handwritten text recognition (HTR) is the automated transcription of handwriting from page images into machine-readable text. It differs from optical character recognition mechanically. OCR was engineered for machine-printed text, classifying one glyph at a time against reliable boundaries, consistent baselines, and known typefaces. Cursive has no clean letter boundaries to segment, so HTR abandons per-glyph classification. It treats a whole text line as one image and maps it to a sequence of characters using sequence models that read the line in context, the way a reader infers an ambiguous letter from the word around it. HTR is trained on real handwriting rather than typefaces.

Why can't OCR read old handwriting or historical print?

OCR fails on old material because it assumes clean glyph boundaries, even spacing, consistent baselines, and a small set of modern typefaces. Cursive connects letters, so there are no boundaries to find; layouts are irregular, and the same scribe writes the same letter several ways on one line. Historical print breaks the same assumptions: blackletter and Fraktur, the long s that OCR reads as an f, ligatures, and macrons standing in for omitted nasals. One 2024 test found a conventional OCR tool misreading roughly half the city names in a nineteenth-century table. The real dividing line is modern-and-regular versus historical-and-irregular, not print versus handwriting.

What is a good character error rate for handwritten text recognition?

On difficult historical material, anything under about 10% character error rate (CER) is respectable, and figures above that are not unusual; a perfect transcription is 0%. Roughly 5% CER is publishable-quality first-pass text, while 15% is usually enough to make a collection searchable but not to quote from without close correction. The trap is treating one number as a fixed property of a tool. Published CERs are almost impossible to compare across studies, because they come from different datasets, evaluation protocols, page splits, and amounts of language-model post-processing. The only number that truly matters is the one you measure on a sample of your own hands.

Can I just paste a handwritten document into ChatGPT to transcribe it?

You can, but it is risky, because the failure mode is subtle. General multimodal chatbots weight linguistic plausibility heavily and downsample the images you upload. On a difficult hand that combination produces fluent errors rather than recoverable ones: a clean, confident, grammatical reading that happens to be wrong, often inserting plausible archaic spellings the source never contained. A specialist model that misreads tends to produce spottable garble instead. A language model also improves average word plausibility and can therefore overwrite a genuinely preserved archaic spelling or abbreviation. A wrong transcription that looks right is more dangerous than one that looks broken, because you will not think to check it.

What does it mean when an HTR tool claims to support "100+ languages"?

A claim of "100+ languages" is really a claim about script coverage plus language priors, not a promise that every hand in every language reads equally well. Honest support has three parts. Script is the writing system: most historical tooling is built for the Latin alphabet, while Greek, Cyrillic, Hebrew, Arabic, and Indic and East Asian systems lag it by years. Language shapes the priors a model brings to ambiguous marks, and coverage is uneven, with English over-represented in benchmarks. Hand is the individual style — secretary, court, italic, Kurrent — and is often the real determinant of success. The honest unit is script, language, and hand together.