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" hides at least four questions: 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.
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. On a page transcribed at 5% CER, something is wrong in most sentences, which is a good deal worse than the couple of typos the figure suggests.
The metric is wrong for genealogy
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 the part that is hardest to read, for one 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, and so are four spellings of the village, or 1857 and 1837.
A document can therefore score an excellent CER because the model got the boilerplate right, and still get wrong the only eight words you came for. A headline accuracy figure describes average legibility across the page and says very little about your ancestor's name.
What the research actually shows
There are 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. 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. For genealogy, the finding to remember is that 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
They tested different material, and the material explains most of the gap.
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.
Read together, the three results say the same thing: 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. A year from now, the more useful comparison will be how well a given pipeline combines the two, which is roughly what the 1.8% corrected figure was already showing.
The two ways a transcription goes wrong
The failure modes matter more than the percentages, because they 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 and 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 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.
The Crosilla finding above rules out the obvious workaround. Models have limited ability to autonomously correct their own errors, so asking one to double-check its work gives you 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.
Unfamiliar scripts. If you cannot read Kurrent, pre-reform Cyrillic cursive, or secretary hand at all, you are comparing AI with nothing at all, and a paleographer's standard is beside the point. A 90% transcription of a document you could not otherwise open changes what you can research, and correcting a suggested word is an 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 enough, because a false positive costs you one minute.
Structure. Turning a wall of prose into labelled fields - name, role, date, place, relationship - is a different capability from transcription, and it is where most of the time saving comes from.
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 test is whether your process catches a transcription 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. 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. The confusion is old: the crossed continental 7 exists because scribes needed to tell the two apart. 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 polished transcription with no image beside it looks good in a demo and leaves you hunting for the source every time you check a name.
What KleioBase does, and what it does not
KleioBase reads and extracts records with AI, and the workflow below has limits as well as features.
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 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.
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 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, you are collecting fluent text about people who may never have existed.
What separates those two outcomes is the ninety seconds you spend looking at the image.
Follow KleioBase on Google
Add us as a preferred source to see our research guides more often in Google Search and AI results.
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


