HTR for Historians: A Practical Guide

This is a working guide to HTR for historians: what handwritten text recognition actually does, how it differs from the tools it gets confused with, how to read its accuracy figures honestly, and how to fit it into research without compromising your sources. Transcription is usually the slowest stage of archival work, and the right instrument moves that bottleneck — provided you understand what it can and cannot do.

Handwritten text recognition (HTR) turns images of handwritten documents into machine-readable text. For historians, it matters because transcription is usually the slowest stage of archival work — the wall between finding a source and analyzing it. Modern HTR reads manuscript hands that general-purpose OCR cannot, and the best systems now transcribe difficult early-modern hands with a character error rate low 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 — 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.

What HTR is, precisely

HTR recognizes 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.
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 HTR vs OCR, and the mechanics of the pipeline — segmentation, recognition, export — in how HTR works.

Why general-purpose OCR fails on manuscripts

The tools most people reach for first — Amazon Textract, Google Cloud Vision, ABBYY FineReader, Tesseract — are engineered around clean, modern, high-contrast print. On a modern scan they are fast, cheap, and accurate. That is what they are for.

They are not built for handwriting, and in several cases they say so plainly: ABBYY's own documentation states that FineReader "supports recognition only of printed text" and cannot recognize handwriting. Tesseract, similarly, was built for printed text and ships with no out-of-the-box handwriting model.

The gap is not confined to handwriting, either. Historical print breaks conventional OCR too. A glyph classifier trained on modern type stumbles over early-modern founts, blackletter and Fraktur, the long s (ſ) read as f, ligatures split or dropped, and the abbreviation marks that early printers carried over from scribal practice. Add the physical realities of an old page — uneven inking, type bite, show-through from the verso, foxing — and a classifier reads that noise as character evidence. This is why "we already have OCR" is not an answer for archival material. The assumptions that make OCR fast on a modern invoice are the same assumptions the source violates on every line.

The three classes of tool a historian actually chooses between

If you are selecting a workflow, the field divides into three groups, each with a distinct trade-off.

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.

General-purpose OCR

The Textract, Vision, and ABBYY class above is strong on modern print and the wrong instrument for manuscripts.

General multimodal LLMs

GPT-4o, Claude, and 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.

Two conventions circulate widely: CER of roughly 10% or below is treated as "usable," and around 5% or below as "research-grade." Transkribus documentation notes that a CER below 10% is considered good for most handwritten material. It is worth being precise about the status of these numbers. They are practitioner conventions from platform documentation, not peer-reviewed cut-offs 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, handled carefully

The honest state of the evidence is this. On a benchmark of 18th–19th-century English manuscripts, Humphries et al. (2024) reported that GPT-4o and Claude reached CER in the range of 5.7–7.0%, matching or bettering a Transkribus baseline that scored between 14% and 32% on the same material. That is a real result and should not be waved away. But it should not be over-read either: it is a single corpus, in one language, on one period of hand, and — as the authors themselves stress — LLM transcription is best treated as a complement to specialist HTR under rigorous human verification, not a replacement for it. Whether the gains survive to French, German, Dutch, Spanish, or Italian hands is unresolved. Whether they survive realistic image resolutions is a further open question, since most multimodal models downsample input images (commonly to 224×224 or 336×336) before processing, 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. An LLM is a text-prior-driven generator, not an image-grounded recognizer, so when it fails it tends to produce fluent, plausible, grammatical prose that is simply not what the page says. That failure mode is far harder to catch, because nothing on the page flags it. A garbled character invites a second look; a confident, well-formed fabrication does not. For a scholar whose conclusions will be cited, that asymmetry matters more than a headline CER. We treat the mechanism in detail 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 analyzing historical documents develops this separation across the full pipeline, and manuscript abbreviations and ligatures covers the marks most often lost in the process.

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 transcription model, ATR-1, 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.

Two design choices matter for the concerns raised above. First, ATR-1 is trained to transcribe what is on the page rather than to normalize it: it preserves strikethroughs, additions, marginalia, tables, and archaic spelling, and it does not silently resolve a contraction into modern prose. Second, any interpretation — correction, modernization, translation, entity extraction — runs as a separate transformation layer that writes to a new tab, leaving the faithful base transcription untouched. That is source integrity enforced by the workflow, not left to discipline alone.

On accuracy, the one cleared head-to-head figure is worth stating with its source. On a randomized 97-image sample of early-modern English manuscripts from the Folger Shakespeare Library, at ATR-1's release, Leo scored roughly 5% CER — 61% fewer errors than the next-best model, with Transkribus's Text Titan I at about 13%, Claude Opus at about 23.3%, Gemini 2.5 Pro at about 24.8%, and GPT-4.1 at about 56.7%. That is one corpus, one period, one hand — not a universal claim — and it does not remove the need to verify. It does show what a model trained specifically on images of historical documents can do on exactly the material that defeats general tools. ATR-1 is not a wrapper around a general LLM: it is a custom transformer fine-tuned to weigh high-resolution visual evidence against context, which is why it is not subject to the downsampling ceiling that caps general multimodal models. Because Leo also reads printed matter — including the historical print, long s and all, that conventional OCR mangles — it serves as general-purpose OCR too, though the case for it is strongest precisely where other tools are weakest.

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. For genealogists, the same principles apply to the specific records they live in — parish registers, old wills, and census records.

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) for historians turns images of handwritten documents into machine-readable text, addressing 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 clean, modern, high-contrast print, not handwriting. ABBYY's own documentation states FineReader supports recognition only of printed text and cannot recognize handwriting; Tesseract ships with no out-of-the-box handwriting model. The gap extends to historical print too: early-modern founts, blackletter, the long s read as f, ligatures, and abbreviation marks all defeat glyph classifiers trained on modern type. Add uneven inking, show-through, and foxing, and the classifier reads that noise as character evidence. "We already have OCR" is not an answer for archival material.

What is a good CER for handwritten text recognition?

By practitioner convention, a Character Error Rate (CER) of roughly 10% or below is treated as "usable," and around 5% or below as "research-grade." Transkribus documentation considers a CER below 10% good for most handwritten material. Treat these as rough guidance, not certificates: they are platform conventions, not peer-reviewed cut-offs validated against downstream reliability. 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, but their failure mode makes them untrustworthy unsupervised. On a benchmark of 18th–19th-century English manuscripts, GPT-4o and Claude reached CER of 5.7–7.0%, matching or bettering a Transkribus baseline — a real result on a single corpus, one language, one period of hand. The deeper problem is the kind of error: an LLM is a text-prior-driven generator, not an image-grounded recognizer, so when it fails it produces fluent, plausible prose that is simply not what the page says. That fabrication is far harder to catch than a garbled character, because nothing on the page flags it.

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 ATR-1 model 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.