HTR for Historians: A Practical Guide to AI Transcription

HTR, or handwritten text recognition, is software that reads images of handwritten documents and turns them into searchable, editable text. For a historian it attacks the slowest stage of archival work, transcription, and the best tools now produce a serious first draft of difficult early-modern hands without any training on your material. The rule that governs its use is simple: an HTR transcription is a draft to check against the image, not a finished text — and this guide shows how to choose a tool, read its accuracy, and fit it into research without compromising your sources.

Transcription is the wall between finding a source and analyzing it. HTR reads manuscript hands that general-purpose OCR cannot, but it is a drafting instrument, not an oracle: its errors — and the errors of the general AI tools often mistaken for it — are not all equally easy to catch.

This guide sits within our broader work on handwritten text recognition as a category; if you are meeting the term for the first time, our practical guide to handwritten text recognition is the place to start.

What is HTR? A precise definition

HTR is the automated recognition of handwritten text in document images. In technical terms, most systems work at the line level, using neural sequence models: convolutional layers extract visual features, then recurrent or transformer layers emit a character sequence. Two architectures dominate the literature — CNN+BiLSTM+CTC systems in the PyLaia mould, and transformer encoder–decoder systems in the TrOCR mould.

A few adjacent terms are worth fixing in place, because they are used loosely and the looseness causes confusion.

ATR (Automated Text Recognition) is the umbrella term. It covers both OCR and HTR, and models that read print and handwriting alike; Leo's own model, ATR-1, takes its name from it.
OCR (Optical Character Recognition) classifies isolated glyphs against a font model, assuming regular letterforms and predictable spacing
HTR is the branch built for handwriting, where letters connect unpredictably and there is no fixed font
Layout analysis is the upstream stage that detects text regions and baselines and orders them for reading — a separate problem from recognizing the characters themselves

The practical point: HTR is not "OCR that also does handwriting." It is a different modeling approach to a harder problem, and the distinction shapes everything downstream. We treat the difference at length in OCR vs HTR, and the mechanics of the pipeline — segmentation, recognition, export — in how HTR works.

The four classes of tool a historian actually chooses between

If you are selecting a workflow, the field divides into four groups, each with a distinct trade-off. (For a product-by-product survey of HTR software, see our comparison.)

Specialist HTR platforms

Transkribus, eScriptorium (on the Kraken engine), and OCR4all are the established route to research-grade transcription. Their strength is accuracy on a specific hand. Their cost is preparation: to reach that accuracy you generally train or fine-tune a model on your own ground-truth transcription. Transkribus guidance suggests at least 25 pages, and 5,000–15,000 words, before you begin training a base model — and that figure is a floor, not a ceiling. Research-grade accuracy on a difficult hand typically demands substantially more. For a scholar with one collection and a deadline, that upfront labor is the central question.

Ready-made specialist models

Models pre-trained on a broad range of historical documents, which you point at a page with no training step. Leo's ATR-1 is one; we come to it below. The trade-off is the reverse of the platforms': no preparation, in exchange for less control over an unusual hand.

General-purpose OCR

Amazon Textract, Google Cloud Vision, ABBYY FineReader and Tesseract are engineered around clean, modern print, and on a modern scan they are fast, cheap and accurate. Textract and Cloud Vision also handle modern handwriting, such as a filled-in form or a recent letter, reasonably well, but a secretary-hand will or a Kurrent parish register is far outside their training; ABBYY's own documentation states that FineReader "supports recognition only of printed text", and Tesseract ships with no out-of-the-box handwriting model. Historical print trips them too (the long s read as f, blackletter, ligatures, archaic spelling "corrected" by a built-in dictionary), which is why "we already have OCR" is not an answer for archival material.

General multimodal LLMs

The general models from OpenAI, Anthropic and Google — ChatGPT, Claude, Gemini — are the newest entrants, and the ones historians most often reach for without thinking of them as transcription tools at all. Their accuracy on some material is genuinely surprising, but their failure mode is the reason they cannot be trusted unsupervised. More on both below.

Reading accuracy figures honestly

The standard measure is Character Error Rate (CER): the Levenshtein edit distance between the transcription and a human-verified reference — substitutions plus deletions plus insertions — divided by the number of reference characters, as a percentage. Word Error Rate (WER) applies the same arithmetic to whitespace-separated tokens, and runs higher, because a single wrong character invalidates a whole word.

How low is low enough depends on the job. A CER of 10% means one character in ten is wrong, an error in roughly every second word: enough to find a keyword, not enough to read, quote or edit from. For reading and citation you want something close to 2% or below. Platform documentation is not consistent on this. Transkribus's help centre describes results with a CER of 10% or below as "very efficient for automated transcription", while its own CER explainer reserves "publication-ready" for under 2% and marks 5–10% as needing review. None of these thresholds is a peer-reviewed cut-off validated against downstream analytical reliability. Use them as rough guidance, not as a certificate.

They also hide two things a historian should watch for. First, a low aggregate CER can conceal systematic errors — a consistent confusion between two letterforms, or a layout misreading — that are far more damaging to search and analysis than the same number of scattered slips. Second, CER says nothing about which characters were wrong. A 3% error rate distributed across names, dates, and sums is not the same problem as 3% across common function words. This is why even a strong CER does not mean the transcription is finished. It means you have a draft worth checking. We set out a working method in our guide to verifying transcription accuracy.

The LLM question, as of October 2026

The honest state of the evidence is this. The general models have improved quickly since 2024, and on some material, especially English hands of the eighteenth and nineteenth centuries, the best of them now read handwriting well. That is a real change and should not be waved away. But it should not be over-read either. The published tests are concentrated on English and on later, more regular hands; whether the results hold for French, German, Dutch, Spanish or Italian hands, or for sixteenth-century secretary and court hands, is still largely unresolved. And the general models still downsample large images before reading them, capping exactly the fine-grained detail a difficult hand demands.

The deeper issue is the kind of error. A specialist HTR system errs at the character level: it misreads a letter, and the mistake usually looks like a mistake. A general model leans on what is linguistically probable, so its surviving errors are fluent: a modern spelling in place of the one on the page, a resolved abbreviation, a likelier word where the ink is faint. Nothing on the page flags them, and for a scholar whose conclusions will be cited, that asymmetry matters more than a headline CER. We treat the mechanism in why LLMs make fluent transcription errors and, specifically, in why ChatGPT struggles with historical handwriting.

Source integrity: the principle that should govern the whole workflow

The purpose of transcription is to represent what is on the page — including the things a modern reader would be tempted to smooth away. Strikethroughs, interlinear additions, marginalia, archaic spelling, the u/v and i/j interchange, the abbreviation marks that stand for absent letters: these are evidence, not noise. A transcription that silently normalizes them has destroyed information before analysis begins.

This is where the "correction" instinct built into general AI tools becomes a liability. A model that resolves a scribal contraction to its expanded form, or "fixes" archaic orthography, is making an editorial decision on your behalf and hiding it. The disciplined practice is to keep the faithful base transcription and any interpretive layer — expansion, modernization, translation — separate and reversible, so a later reader can always see what the page actually held. Our guide to historical language normalization develops this separation, and manuscript abbreviations and ligatures covers the marks most often lost in the process; for English hands, the abbreviation pages in the Leo Academy Handbook show each mark with real examples.

Where a purpose-built model fits — and where Leo comes in

If your material is Latin-script — English, French, German, Dutch, Spanish, Italian, Latin, or any other language written in that alphabet — and the bottleneck is getting from image to a trustworthy first draft without a per-collection training project, this is the stage where Leo is built to help. Its own model, ATR-1, is a Transformer tuned specifically for historical documents. It is zero-shot: it reads out of the box, with no ground-truth preparation and no model to train first. That removes the 25-page floor entirely for the common case of a scholar who simply needs to read a collection.

Its design answers the concerns raised above:

Source integrity. ATR-1 is trained to transcribe what is on the page rather than normalize it. It does not over-correct or silently modernize: strikethroughs, additions, marginalia and archaic spelling are preserved, and a contraction is not silently resolved into modern prose. Any interpretation — correction, modernization, translation, entity extraction — runs as a separate Transformation in a new tab, leaving the base transcription untouched: source integrity enforced by the workflow, not left to discipline.

Corrections made in Leo feed back into training, so the model improves with each release. Because ATR-1 also reads printed matter — including the historical print, long s and all, that conventional OCR mangles — one tool covers a series that mixes manuscript and print. It does not remove the need to verify.

ATR-1 is the default in Leo's model library, at 1 credit an image. The same menu holds the large general models from OpenAI, Google Gemini and Anthropic Claude, which you can run on a hard page as a second reading — each run lands in its own tab, so you can compare them against each other and the image — and small, cheap models for clean, legible print such as a nineteenth-century book or a typescript. Leo never sells user data to third parties, and is UK and EU GDPR compliant, which matters if you are working with unpublished material.

Which approach suits which project

One collection, a deadline, hands of the last five centuries: A ready-made specialist model such as ATR-1: no training step, transcription beside the image
A large, homogeneous collection in an unusual hand: Consider training a model on a specialist platform; the ground-truth effort is repaid across many pages
A series mixing manuscripts and early-modern print: One model that reads both, such as ATR-1, so print and hand are a single workflow
Clean, legible printed sources you only need to read and search: A small, cheap model or a conventional OCR engine

Whatever you choose, test on a sample of your own pages before you commit a collection to it. A published figure for someone else's material is no substitute.

A workflow for a research project

A defensible HTR workflow for a thesis, an article or an edition looks something like this:

Pilot. Pick a dozen images that represent the series, including the hardest, and key a reference transcription of a few lines from each.
Choose the model. Run the pilot through one or two candidates and count the errors that matter to you, not just the total.
Run the collection. To recognize handwritten text from an image, you upload the photograph or scan and run the model on it; in Leo you upload the images as a document, run ATR-1 on one image or all of them, and read each transcription beside its image. Academics, archives and libraries can apply for the Leo Transcription Grant (up to 100,000 free credits), on condition that images and transcriptions are published openly (CC0) within 24 months, so apply with material you have the right to publish.
Take a second reading of hard pages. Run a second model where a page is faded or a hand unusual; disagreement marks the places to look.
Verify against the image. Names, dates, sums and anything you will quote first.
Keep the layers separate. A faithful base transcription; expansions, modern spelling and translations in their own layer.
Record what you did. The model, the date, and how you checked the output.
Export. TEI XML for an edition; Word, PDF or HTML for working copies.
Cite it. Say the transcription was machine-assisted and human-verified; see how to cite an AI-assisted transcription.

Fitting HTR into the research pipeline

HTR is one stage, not the whole workflow. Upstream comes capture — photographing documents in the reading room well enough that recognition has something to work with. Alongside sit organization and description: image-management tools such as Tropy hold and catalogue your research photos but do not read them, a division of labor we set out in our comparison of Tropy and transcription workflows. Downstream come metadata, TEI encoding, and the analytical work the transcription exists to serve. Fitting these together is the subject of our archival digitization workflow guide.

The material itself imposes the last constraint. No tool relieves you of knowing your hands, and the standard reading references remain essential: our guides to reading secretary hand and to early modern paleography exist because the historian who cannot recognize a mistranscribed letterform cannot verify anything a machine produces. If you want structured practice, Leo Academy's free English secretary hand course works through the hand with real scribes' examples. For genealogists, the same principles apply to the specific records they live in — parish registers, old wills, and census records — and to the Latin terms in genealogy records that turn up in all of them.

What HTR changes, and what it does not

Used well, HTR moves the bottleneck. It turns weeks of hand-transcription into hours of drafting and review, and it makes a collection searchable in ways paper never allows. That is a genuine shift in what a single researcher can attempt.

What it does not change is the historian's responsibility to the source. Every automated transcription is a hypothesis about the page, to be checked against the image, with the high-stakes tokens — names, dates, sums, quotations you intend to publish — checked first and hardest. The skill of paleography is not made obsolete by the machine; it is what lets you use the machine safely. The right question is never whether to trust the tool, but where in your workflow its output stops being a draft and becomes evidence — and that line is one only you can draw.

Frequently Asked Questions

What is HTR for historians?

HTR (handwritten text recognition) is software that turns images of handwritten documents into machine-readable text. For historians it addresses the slowest stage of archival work: transcription. Unlike general-purpose OCR, which classifies isolated glyphs against a font model, HTR uses neural sequence models built for handwriting, where letters connect unpredictably and there is no fixed font. The best systems now transcribe difficult early-modern hands well enough to serve as a serious first draft. But HTR is a drafting instrument, not an oracle: its output still requires verification against the image, because its errors are not all equally easy to catch.

Why can't I just use Google Cloud Vision or ABBYY to transcribe old manuscripts?

Because tools like Amazon Textract, Google Cloud Vision, ABBYY FineReader, and Tesseract are engineered around modern material. Textract and Cloud Vision read modern handwriting reasonably well, but a secretary-hand will or a Kurrent register is far outside what they were trained on. ABBYY's own documentation states that FineReader supports recognition only of printed text, and Tesseract ships with no out-of-the-box handwriting model. The gap extends to historical print too: the long s read as f, blackletter, ligatures and archaic spelling all trip engines trained on modern type. The full comparison is in our guide to OCR vs HTR.

What is a good CER for handwritten text recognition?

At a Character Error Rate (CER) of 10%, roughly every second word contains an error: enough for keyword search, not for reading or quoting. For reading and citation, aim for about 2% or below. Platform guidance varies: Transkribus's help centre calls 10% or below "very efficient for automated transcription", while its own CER explainer reserves "publication-ready" for under 2%. Treat any threshold as rough guidance, not a certificate. A low aggregate CER can also hide systematic errors — a consistent letterform confusion or layout misreading — and says nothing about which characters were wrong. A 3% error rate across names, dates, and sums is not the same problem as 3% across common function words.

Can ChatGPT or Claude transcribe historical handwriting accurately?

Sometimes, and better than they used to, but not unsupervised. As of October 2026 the best general models read many later, regular hands well, mostly in English; how far that holds for older hands and other languages is still open. The bigger problem is the kind of error: a general model leans on what is probable, so its mistakes are fluent — a modern spelling in place of the one on the page — and nothing flags them. A model built for historical documents, such as Leo's ATR-1, is trained to keep what is on the page and shows its transcription beside the image.

Does HTR normalize archaic spelling and abbreviations, or keep them faithful?

It depends on the tool, and the difference matters. Strikethroughs, interlinear additions, marginalia, archaic spelling, the u/v and i/j interchange, and abbreviation marks are evidence, not noise; a transcription that silently normalizes them destroys information before analysis begins. The "correction" instinct built into general AI tools is a liability here, resolving a contraction or fixing orthography while hiding the editorial decision. Leo's own model, ATR-1, is trained to transcribe what is on the page rather than normalize it, and runs any interpretation — correction, modernization, translation — as a separate layer that leaves the faithful base transcription untouched.

Which kind of tool should a historian use for transcription?

It depends on the project. For one collection on a deadline, a ready-made specialist model is the quickest route to a usable draft: Leo's ATR-1 is tuned for historical handwriting and print, keeps the page's own spelling, and needs no training on your material. For a very large collection in one unusual hand, training a model on a specialist platform can repay the ground-truth effort. For clean, legible printed sources, a small, cheap model or a conventional OCR engine is usually enough. Whatever you choose, test it on a dozen of your own pages first, and check names, dates and sums against the image.