Research

How Accurate Is AI at Reading Old Handwriting?

KleioBase EditorialAugust 28, 202615 min read
Share

Ask how accurate AI transcription is and you will get numbers between 1.8% and 35% error, depending on who you ask. All of those figures are real, recently measured, and published by people with no reason to lie.

They disagree because "how accurate is it" is not one question. It is at least four: on which language, in which hand, measured how, and accurate about what. Genealogy happens to care about the one part of a page that AI is worst at, which is why a transcription can be 97% correct and still useless to you.

This is what the evidence currently shows, and what to do about it.

How transcription accuracy is measured

The standard metric is character error rate, or CER. It is the edit distance between the machine transcription and a human-verified ground truth, normalised by the length of the reference:

CER = (S + D + I) / N

Where S is substituted characters, D is deleted characters, I is inserted characters, and N is the total characters in the reference. Word error rate (WER) does the same at word level, and is normally the harsher of the two, because a single wrong character ruins an entire word.

Transkribus, the specialist platform in widest use here - more than 150 universities and archives run on it - publishes rough tiers for what a CER means in practice: under 2% is publication quality and needs little review, 2 to 5% is good enough for most research workflows with spot checks, and 5 to 10% is usable for search and indexing but needs review before you trust it.

It helps to translate those percentages into something physical. The average English word is about 4.7 characters, so with the space after it you get roughly six characters per word. A 5% CER means one wrong character in every twenty, which works out at an error every three or four words. A page of transcription at 5% CER is not a page with a couple of typos. It is a page where something is wrong in most sentences.

The metric is wrong for genealogy

Here is the part that almost nothing written on this subject says out loud.

CER treats every character as equally important. Genealogy does not. Open any parish register entry and perhaps 80% of the characters are formulaic boilerplate: the standing phrases of the register, the clerk's stock formulas, the printed headings, the ecclesiastical Latin that reads the same in every entry for two hundred years. You do not need any of it.

What you need is the surname, the given names, the day, the month, the year, the place, the age, and the occupation. That is a small minority of the characters on the page, and it is precisely the part that is hardest to read, for a very specific reason: proper nouns and numerals carry no linguistic context.

Every recognition system, whether a purpose-built handwriting model or a large language model, leans on context to resolve ambiguous letter shapes. If the model can only read "b_ptiz_tus" it recovers the word instantly, because there is exactly one word it can be. Faced with the same quality of handwriting in a surname, there is nothing to recover from. Wójcik, Wójcek, Wójcyk and Wojcik are all plausible. So are four spellings of the village. So is 1857 versus 1837.

Which means a document can score an excellent CER because the model nailed the boilerplate, and still get the only eight words you actually came for wrong. A headline accuracy figure tells you about the page. It tells you very little about your ancestor's name.

Treat every published CER as a statement about average legibility, not about the fields you care about.

What the research actually shows

Three serious pieces of recent evidence, and they do not agree.

Humphries et al., 2024. A team led by the historian Mark Humphries at Wilfrid Laurier University, posted to arXiv in November 2024 and published in Historical Methods in 2025, tested frontier language models against specialist HTR software on a corpus of 18th and 19th century English handwritten documents. The models produced character error rates of 5.7 to 7% and word error rates of 8.9 to 15.9%, which they report as improvements of 14% and 32% respectively over state-of-the-art HTR software including Transkribus. More striking: when a model was used to correct transcriptions - its own or those produced by conventional HTR - accuracy reached 1.8% CER and 3.5% WER, which is roughly human level. They also measured the task running about 50 times faster and at around one fiftieth of the cost.

Crosilla, Klic and Colavizza, 2025. A benchmarking study, published in the Journal of Documentation, across proprietary and open-source models against Transkribus, on modern and historical datasets in English, French, German and Italian. Their conclusion is deliberately deflationary: comparisons with Transkribus show no consistent advantage for either approach. Proprietary models outperformed open-source ones in zero-shot settings, models did notably better on modern handwriting than historical, and they showed a marked preference for English, which the authors attribute directly to what these models were pre-trained on. One finding matters more than the headline: the models demonstrated limited ability to autonomously correct errors in their own zero-shot transcriptions.

Transkribus, June 2025. Transkribus benchmarked its own Text Titan I ter model against several language models on a 2,000-page sample drawn from its corpus of roughly 7 million pages across about 9,000 archival sources, covering 13 languages and excluded from all training sets. Their result: 10.8% CER on handwritten text for their model, against 35.0% for the best-performing language model tested. On printed text, 3.9% against 10.2%.

So one study says language models beat specialist HTR by a comfortable margin. Another says there is no consistent winner. A third says specialist HTR wins by more than three times.

Why they disagree

The corpora disagree, and the corpora are the experiment.

The study most favourable to language models used 18th and 19th century English. The study finding no clear winner covered four languages and reported an explicit English bias. The study most favourable to specialist HTR used 13 languages across nine thousand archival sources, deliberately sampled for variety of hand, layout and document type.

That is not three contradictory answers. It is one consistent answer stated three ways: general-purpose models are strongest on the material that resembles their training data and degrade steeply as you move away from it. English, reasonably legible, 19th century, conventional layout is their best case. Nineteenth-century Kurrent in a cramped Prussian civil register, or a Cyrillic parish record with a marginal note in a different hand, is not.

Two caveats on reading these numbers yourself. The Transkribus benchmark is a vendor testing its own product on a test set it selected, which is data rather than a verdict - though in fairness, a multilingual archival sample is far more representative of European genealogy than an English-only corpus. And all of these numbers age in months. A benchmark from eighteen months ago describes models that have since been replaced. Treat the pattern as durable and the specific figures as perishable.

There is also a reason not to get too attached to the contest itself. Writing in May 2026, IEEE Spectrum reported both that general models had pulled ahead of Transkribus on accuracy, speed and cost in Humphries' testing, and that Transkribus has announced it will integrate language models directly into its own platform. The interesting question a year from now will not be specialist versus general. It will be how well a given pipeline combines them, which is roughly what the 1.8% corrected figure was already showing.

The two ways a transcription goes wrong

This matters more than the percentages, because the failure modes are not equally dangerous.

Classic OCR failure produces garbage that looks like garbage. You get Wó1ci|< or a run of nonsense characters, and you know instantly that something went wrong. The error announces itself. It costs you a few seconds.

Language model failure produces fluent, plausible, grammatical text that is wrong. This is the defining risk, and it follows directly from what these models are. A model that has absorbed an enormous quantity of text knows what a 19th-century Polish parish register sounds like. Confronted with a surname it genuinely cannot read, it does not stop. It produces a surname - a real one, correctly spelled, of the right nationality for the region, sitting comfortably in a well-formed sentence.

There is no visual signal that this happened. A confabulated surname looks exactly like a correctly read one. Without the image in front of you, the two are indistinguishable, and the invented one is often the more convincing of the pair, because real handwriting produces awkward-looking readings and invention does not.

There are three related behaviours worth watching for:

  • Silent normalisation. Models regularise archaic spelling, expand abbreviations, and modernise orthography without mentioning it. Convenient for reading, damaging for citation, and occasionally destructive: the archaic spelling was sometimes the evidence.
  • Completing the pattern. Given a column of dates where five are legible and one is not, a model will produce a sixth that fits the sequence.
  • Confidence with no basis. By default you get no honest uncertainty signal. The model does not flag the surname it guessed, because from the inside a guess and a reading are the same operation.

And note the Crosilla finding from above, because it kills the obvious workaround: models have limited ability to autonomously correct their own errors. "Ask it to double-check its work" is not a control. It is the same system marking its own exam.

Where AI genuinely beats you

None of this is an argument against using it. The strengths are real and specific.

Stamina and consistency. It reads page 300 exactly as carefully as page 1. No human does. Most transcription errors in the historical record were made by tired humans, not machines.

Unfamiliar scripts. If you cannot read Kurrent, pre-reform Cyrillic cursive, or secretary hand at all, the relevant comparison is not "AI versus a paleographer". It is "AI versus nothing". A 90% transcription of a document you could not otherwise open is transformative, and correcting a suggested word is a fundamentally easier cognitive task than producing one from a blank page. See our guides to Kurrent and Sütterlin and to Russian-language records for what those scripts involve.

Boilerplate at speed. The formulaic 80% that you do not need to check is exactly what it handles best.

Triage. Deciding which forty pages of a four-hundred-page register are worth your attention is a task where 90% accuracy is entirely sufficient, because a false positive costs you one minute.

Structure. Turning a wall of prose into labelled fields - name, role, date, place, relationship - is a genuinely different capability from transcription, and it is where most of the time saving actually lives.

What it does not do is the judgement: whether the informant was reliable, whether "Russia" on this document means a contested border region, which of two conflicting ages to believe. That part has not moved. We wrote about the division of labour in more detail in how AI is transforming genealogical research.

A verification workflow that works

The useful question is not whether AI transcription is accurate enough. It is whether your process catches it when it is wrong. Eight rules, in rough order of value.

1. Never accept a proper noun you have not seen with your own eyes. This is the whole discipline in one line. Read the boilerplate; verify the names, dates and places against the image, character by character. It is far less work than it sounds, because it is a small fraction of the page and you know exactly where to look.

2. Check numerals separately, and slowly. Digits have no context to fall back on, which is why they are guessed. Continental hands are a specific hazard: a 1 written with a long upstroke reads as a 7 to almost every system. That confusion is not a modern artefact - the crossed continental 7 exists precisely because scribes needed to tell the two apart - but a machine does not always apply the convention the writer did. The same goes for 3 against 8 and 5 against 6 in worn ink. If a date matters, verify it twice.

3. Keep the original-language transcription, not just the translation. Translation is a second lossy step layered on the first. If you only keep the English, you have thrown away the evidence and kept the interpretation, and you can never audit it again without refetching the image.

4. Use the document's internal redundancy. Records check themselves more than people expect. An age and a birth year should agree. A surname usually appears three or four times in one entry. Formulaic entries state the same fact twice in different phrasings. Where the transcription is internally inconsistent, one of the two readings is wrong and you have just been told where to look.

5. Read the neighbouring entries. Same clerk, same hand, same formula, same week. A letter shape you cannot resolve in your entry is frequently unambiguous three entries down where the ink held better. This is the single highest-yield paleography habit there is, for humans and as a check on machines.

6. Disagreement is a free signal. If you have access to two systems, running a difficult page through both and comparing is cheap. Where they agree, confidence rises sharply. Where they diverge, you have found the hard words without having to hunt for them.

7. Prime it before it reads. Telling a system the language, the region, and the approximate year before transcription measurably improves the result, because it narrows the space of plausible names and formulas. Do this when the tool allows it.

8. Record what you did not verify. If you accepted a transcription without checking it against the image, that is a fact about your research, and it belongs in your notes alongside the negative results. Unverified is not the same as wrong, but future-you cannot tell the difference from a clean-looking transcript.

What this means when choosing a tool

Raw transcription quality is converging and will keep converging. Within a couple of years it will not be a meaningful differentiator. What will still matter is whether the tool is built for the verification problem or against it:

  • Does it keep the image beside the text, so checking a name takes one glance rather than a file hunt?
  • Does it keep the original-language transcription alongside the translation, or does it hand you only the English?
  • Does anything get written to your records automatically, or is there a review step you have to pass?
  • When you correct something, is the correction kept, or does it evaporate on the next run?
  • Can you prime it with language, place, and date?

A tool that returns a beautiful transcription and no image is optimised for a demo. A tool that makes the check quick is optimised for research.

What KleioBase does, and what it does not

We use Google Gemini for extraction. Here is the workflow, including the parts that constrain it.

Before processing, you can add context - the language, place, and approximate year - and draw region boxes to point at the part of the page that matters. Both improve the result, for the reason given in rule 7. For genuinely difficult hands there is a deep scan option that runs a stronger model, spending considerably longer on the page at a higher credit cost; it exists because a single model tier is the wrong answer for a corpus that ranges from clean printed forms to a village priest's worst handwriting.

Extraction produces a transcription in the document's original language and script, which is never translated, alongside a translation and structured fields in your chosen output language. Both are kept. You are never left holding only the English.

Nothing reaches your knowledge base automatically. A processed record enters a Review state, where every field is editable next to the image: you read the transcription, correct what is wrong, exclude any person whose name is too unclear to trust, and only then confirm. Corrections are kept, and confirming is what creates profiles. The details are in uploading records.

Two honest limitations. First, we do not publish a headline accuracy figure, and we are not going to. A single CER averaged across Kurrent, Cyrillic, Hebrew, Latin and English, across four centuries of handwriting, would be a marketing number rather than an informative one, and by the argument in the second section of this article it would not tell you what you actually want to know about the surname on your page. Second, the review step is not decorative. It is where the confabulated surname gets caught, and a tool cannot do that part for you, because catching it requires looking at the image.

The real question

"Is AI accurate enough for genealogy" is the wrong framing, and it produces two equally bad answers: uncritical adoption, and refusing a tool that would open records you cannot otherwise read.

The better question is narrower. Is it accurate enough on the eight words I actually need, and does my workflow put the image in front of me while I check them?

If yes, then a technology that reads scripts you cannot, never tires on page 300, and turns a photograph into structured data is one of the most useful things to happen to this field in a generation. If no, then you are not doing research. You are collecting fluent text about people who may never have existed.

The difference between those two outcomes is not the model. It is the ninety seconds you spend looking at the image.

Start building your family history

Upload a record and let KleioBase transcribe, translate, and connect it - all in one place, with a research partner that remembers everything you find.

Get started

We use cookies and similar technologies. Essential cookies keep the site working. We only load analytics (PostHog) and marketing (Meta Pixel) with your consent. See our Privacy Policy.