Can AI Read Old Handwriting? What Current Models Manage, and Where They Fail

This is a practical assessment of whether AI can read old handwriting — what today's models genuinely manage on historical hands, and the six ways they fail. If you are deciding what to trust with a manuscript series, the useful question is not whether a model reads handwriting but which errors it produces, and whether you can see them.

Yes — current AI can read old handwriting, and on many documents it reads well enough to save weeks of work. But "can it read" is the wrong unit of measurement. Performance on historical hands varies by more than an order of magnitude depending on the script, the period, the condition of the page, and which of three quite different technologies you are actually using; the same model can score under 2% character error rate on one corpus and over 40% on another.

That last point is where most disappointment comes from. A system that garbles a word tells you it struggled. A system that quietly replaces a difficult word with a plausible one does not.

Three different technologies get called "AI reading handwriting"

Before comparing results, separate the mechanisms, because they fail in different ways.

Optical character recognition (OCR)

OCR was engineered for machine-printed text with consistent typefaces. It classifies glyphs against a known type model — segment the page, isolate the character, match it. On a clean modern scan this is fast, cheap, and highly accurate.

Handwritten text recognition (HTR)

HTR treats a line as a sequence and decodes it jointly with a context model, because no two writers form a letter identically and the boundary between letters is often not visible at all. The architectural lineage runs from hidden Markov models through recurrent networks with CTC decoding, to attention-based sequence-to-sequence models, to Transformer encoder–decoders such as Microsoft's TrOCR, which performs visual understanding and text generation in one end-to-end model rather than classifying characters one at a time. If you want the fuller technical picture, our guide to handwritten text recognition covers how the field arrived here.

General vision-language models

The chat assistants read an image as tokens alongside text. They are capable generalists, and they are the thing most people reach for first. They are also the least constrained: their fluency is a language-model fluency, and nothing in their design obliges them to prefer what is on the page over what the sentence probably said.

The distinction matters because the three technologies are frequently benchmarked as though they were doing the same job. They are not. Our practical guide to HTR works through the differences in more depth.

What current models genuinely manage

The good news is real and worth stating plainly.

Modern handwriting is close to solved. On the standard research datasets of contemporary handwriting — IAM for English, RIMES for French — error rates are now in the low single digits. TrOCR LARGE reaches 2.89% CER on IAM. In a 2025 benchmarking study in the Journal of Documentation, general models tested zero-shot came in around 1.7% CER on IAM and 1.6–1.7% on RIMES — figures competitive with, and on those particular modern corpora sometimes better than, a specialist platform's out-of-the-box model. That result is worth keeping in proportion: it is one paper, on clean modern handwriting, with the same models collapsing on the historical sets in the same study, and it does not speak to faithfulness at all.

A trained model on a known hand does very well. Where a research team has invested in ground truth for a specific hand, the numbers are genuinely research-grade. The Egerton model for English secretary hand (1530–1650, built on National Archives material) reports roughly 3% CER off the back of some 750,000 training words. A TrOCR study on sixteenth-century Latin-language manuscripts — the Gwalther corpus, 142 pages — reached 1.86% CER for a single model and 1.60% with an augmentation ensemble. Those marks travel: the same architectures, trained on the same alphabet, handle vernacular hands written in it.

Historical print is often handled better than people expect, though not by the tools built for invoices. Large-scale newspaper digitization under IMPACT and Europeana Newspapers reported character accuracy in the 85–94% band — usable for search, thin for scholarship.

So: on the right material, with the right tool, machine transcription is now a serious research instrument. The failures are equally specific.

Where current models fail

Failure 1: the corpus cliff

The most misleading thing in this field is a bare percentage. In the Journal of Documentation study, Claude 3.5 Sonnet scored 1.75% CER on IAM and 41.19% CER on the ICDAR2017 historical set — the same model, the same prompts, a roughly twenty-four-fold spread. GPT-4o came in around 60% CER on the same historical material. On nineteenth-century Italian handwriting (the Leopardi corpus) Claude landed at 26.43% CER; on the LAM historical dataset, 20.55%.

Read that as a warning about generalization. A model that has seen a great deal of modern cursive has not thereby seen court hand, Kurrent, or a notarial cursive from 1690. And LLM vision capability moves fast enough that every one of these figures is a dated snapshot of a specific model version.

Failure 2: fluent rewriting rather than visible error

This is the failure mode that costs scholarship the most, because it survives proofreading.

A purpose-built recognizer that misreads produces a wrong character or a wrong word — visibly odd, checkable against the image. A general vision-language model under pressure tends instead to produce a better reading than the page supports. A preprint from Lee et al. puts it bluntly: these models "do not always act as faithful transcribers"; when the text is imperfect they rewrite it into a more plausible form, and the rewriting is gated by how similar the model's internal representation of the observed word is to a familiar one. Vesalainen et al.'s comparison of TrOCR and a vision-language model on eighteenth-century English print shows the same behaviour concretely: the VLM achieved a lower CER partly because it normalized historical orthography — "Antient" silently becoming "Ancient."

Consider what that does to a corpus. Spelling variation is evidence: of date, of region, of scribe, of literacy. A tool that improves it away has not transcribed your document; it has edited it, without telling you. We treat this at length in Fluent but Wrong: understanding LLM transcription errors, and if you want to see it happen on a real page, our tests of Gemini on manuscript hands and of ChatGPT on historical handwriting show the pattern in detail.

Failure 3: general OCR is not attempting this task

Sending a manuscript to a print-OCR engine is not a marginal choice; it is a category error. Tesseract was built for printed text — one practitioner benchmark puts it at 38.75% average accuracy on handwriting, and independent practitioner reviews report a similar 20–40% band (tertiary sources, treat as indicative rather than definitive). More decisively, Amazon has stated that Amazon Textract does not currently support handwriting recognition. Cloud OCR services exceed 99% accuracy on clean printed text and degrade sharply on cursive.

Historical print breaks these engines too, for structural reasons: the long s read as f, ligatures split or dropped, macrons and brevigraphs standing for absent letters that a glyph classifier has no representation for, uneven inking and show-through read as character evidence, archaic orthography "corrected" by post-processing. Even print-specialist historical pipelines are the wrong instrument for manuscript — OCR4all, for instance, is a print pipeline for early books and Fraktur, not a handwriting tool.

Failure 4: layout, tables, and pages that mix print with handwriting

Almost every reported accuracy figure is a line-level figure on reasonably clean prose. Real archival series are not that. The Europeana Newspapers evaluation recorded text-line segmentation at 81.6% and page-layout analysis at 87.9% — a reminder that finding the text is a separate problem from reading it, and that layout errors scramble column order in ways no CER figure captures.

The hardest single case across the field is the pre-printed form filled in by hand: deed books, ledgers, station registers, census schedules. The printed structure is high-contrast and regular; the manuscript entries are neither, and models can favour the headers over the entries that matter. For anyone working deed records, census and civil registration, or handwritten weather logbooks, this — not letterform recognition — is usually the binding constraint.

Failure 5: hands and languages nobody has benchmarked

Published figures cluster around a handful of well-studied corpora. For court hand, chancery hand, Spanish notarial cursive, Italian mercantile hands, and much of Scandinavian and Central European chancery material, there are no widely cited error rates at all. Where multilingual figures do exist they are sobering: one Transkribus experiment across a mixed archival corpus reported 12.5% CER for English, 17.1% for Dutch, and 30.7% for German pages.

Two clarifications are worth making here, since they cause persistent confusion. First, script is not language: Latin script is the alphabet used to write English, French, German, Dutch, Spanish, Italian and Latin alike, and a model's real constraint is the writing system, not the tongue on the page. Non-Latin scripts — Greek, Cyrillic, Hebrew, Arabic, Indic and East Asian systems — are a different problem requiring different models. Second, transcription is not translation; they are separate operations, and a tool that does one does not automatically do the other. Our guide to which languages and scripts HTR can read explains why marketing language-counts mislead.

Failure 6: the photograph

Every model is downstream of your image. A NIST study on machine print found that degrading image quality lifted character error rates from 1% to as high as 74% — on the easy task. Blur, raking light, keystone distortion, and heavy JPEG compression cost you more accuracy than any model choice will win back, which is why how you photograph documents in the reading room is part of the transcription question, not a preliminary to it.

How to read an accuracy claim before you trust it

Character error rate is the edit distance — insertions, deletions, substitutions — between output and reference, divided by the length of the reference. Word error rate is the same calculation at word level, and is always higher, because one wrong character condemns the whole word.

What counts as good depends entirely on what you are doing with the text. Transkribus's own thresholds are a sensible public yardstick: under 2% CER for scholarly editions, 5–8% for reliable full-text search, 10–15% for keyword spotting. Their guidance for people training models is to aim for 10% or better for search-grade output.

So when you meet a number, ask four things: which corpus, which hand and period, which model version, and against whose ground truth. A figure without those is decoration. Our piece on what AI transcription accuracy actually measures goes further into why confidence scores and headline percentages mislead.

The training question: who pays the ground-truth cost

Specialist HTR platforms achieve their best numbers by fine-tuning on your material. That is also their price of entry. Transkribus documentation asks for at least 25 transcribed pages before training and roughly 5,000–15,000 words in practice; eScriptorium requires you to supply ground truth before Kraken can learn your hand. The Egerton model's 750,000 words show where the ceiling sits for a difficult hand done properly.

For a funded project with a homogeneous series, that investment pays back. For a researcher with eighty pages of one clerk's hand and forty of another's, it never does — you would transcribe the corpus by hand before the model was ready. The alternative that large heritage backlogs have historically used is volunteers: Zooniverse finds two to five transcribers per image sufficient for a generally accurate result, and the Library of Congress authenticates through second-volunteer review. Accurate, and rate-limited by human availability. The consensus best practice is hybrid — machine first pass, human review and correction.

Where a ready-made specialist model fits

This is the gap Leo was built for: a specialist recognizer for Latin-script material that arrives already trained, so there is no per-corpus ground-truth step, and no per-office or per-collection model to maintain. It reads any language written in the Latin alphabet — English wills, French notarial acts, German parish books, Dutch ledgers, Latin-language texts among them — in manuscript hands and in print, historical or modern.

The design commitment that matters most for the failure modes above is source integrity: transcribe what is on the page. Archaic orthography survives, strikethroughs and marginal additions are recorded, expansions are marked rather than smoothed. Nothing is silently regularized into modern prose, and analysis — correction, modernization, translation, summary — happens as a separate Transformation writing to its own tab, leaving the base transcription intact. Against the repetition-loop and fabrication behaviours any text-generating model can fall into, ATR-1 checks its own output for failure patterns, hides and retries suspect results, and refunds the credit if it cannot succeed. That is a mechanism, not a promise of perfection; the errors that get through are the recoverable kind, a wrong character checked against the image beside the text.

On accuracy, one dated figure, with its scope stated: on a randomized 97-image sample of early-modern English manuscripts from the Folger Shakespeare Library, at ATR-1's release, Leo scored approximately 5% CER, against roughly 13% for Transkribus Text Titan I, 23.3% for Claude Opus, 24.8% for Gemini 2.5 Pro and 56.7% for GPT-4.1 — 61% fewer errors than the next-best model, with the full comparison published here. That is one corpus, one language, one hand family, at one point in time — precisely the caveat this article has been arguing for. The honest weak spot is the one named above: pages where dominant printed structure competes with dense handwriting, such as pre-printed ledger and deed-book forms, where the printed elements can win attention. If you are choosing between tool classes rather than reading about them, our comparison of handwriting transcription software is the fuller treatment.

What this changes about how you work

The useful reframing is this: machine transcription has moved the bottleneck, not removed it. First-pass reading of a long series is no longer the expensive part. Verification is — and verification is a paleographic skill, not a software feature. You need to know which letterforms are systematically confusable in the hand in front of you, which abbreviation marks a model might resolve without saying so, and which fields in your document type carry the risk: names, dates, sums, boundary calls.

That means the discipline holds. Keep the base transcription separate from any interpretation of it. Check names and numbers against the image every time, whatever the CER. Learn enough of the hand you are working in to catch a reading that is too good to be true. The machine now gives you a draft of the page in seconds; deciding what the page actually says is still, as it has always been, your job.

Frequently Asked Questions

Can AI read old handwriting?

Yes — current AI can read old handwriting, and on many documents it reads well enough to save weeks of work. But performance varies by more than an order of magnitude depending on script, period, page condition and which technology you use. The same model can score under 2% character error rate on modern handwriting and over 40% on a historical set. Trained specialist models do research-grade work on known hands: roughly 3% CER for English secretary hand, under 2% on sixteenth-century Latin manuscripts. The useful question is not whether a model reads handwriting but which errors it makes, and whether you can see them.

What is the difference between OCR and HTR?

OCR was engineered for machine-printed text: it segments the page, isolates each glyph and matches it against a known type model. That works on clean printed scans and degrades sharply on cursive, because handwritten letters are formed differently by every writer and the boundaries between them are often invisible. HTR treats a line as a sequence and decodes it jointly with a context model, using architectures that run from hidden Markov models through recurrent networks to Transformer encoder–decoders. Sending a manuscript to a print-OCR engine is not a marginal choice — it is a category error, and the accuracy figures reflect that.

What is a good character error rate for historical transcription?

It depends entirely on what you are doing with the text. Transkribus publishes a sensible public yardstick: under 2% CER for scholarly editions, 5–8% for reliable full-text search, and 10–15% for keyword spotting, with 10% or better the target when training your own model. Character error rate is the edit distance — insertions, deletions, substitutions — between output and reference, divided by reference length. Word error rate is the same calculation at word level and is always higher, since one wrong character condemns the whole word. Always ask which corpus, hand, period, model version and ground truth a figure describes.

Why do AI models change the spelling in old documents?

Because general vision-language models are not obliged to prefer what is on the page over what the sentence probably said. Under pressure they produce a better reading than the page supports, rewriting imperfect text into a more plausible form. One comparison on eighteenth-century English print found a vision-language model achieved a lower error rate partly because it normalized historical orthography — "Antient" silently becoming "Ancient." Spelling variation is evidence of date, region, scribe and literacy. A tool that improves it away has edited your document rather than transcribed it, and the change survives proofreading because it reads correctly.

Why do pre-printed forms like deed books and census schedules cause problems?

Because the printed structure is high-contrast and regular while the handwritten entries are neither, so models can favour the headers over the entries that matter. This is the hardest single case across the field: deed books, ledgers, station registers and census schedules. It is also a layout problem as much as a reading one — finding the text is separate from recognizing it, and one large newspaper evaluation recorded text-line segmentation at 81.6% and page-layout analysis at 87.9%. For anyone working these record types, that competition between print and manuscript, not letterform recognition, is usually the binding constraint.