HTR vs OCR: What the Difference Is, and When It Matters for Historical Documents

Explains the practical difference between OCR and HTR for historical documents, showing how each handles print and handwriting, where both fail, and why ATR matters.

Leo Team

July 14, 2026

HTR vs OCR: What the Difference Is, and When It Matters for Historical Documents

This is a working guide to HTR vs OCR — what each technology actually does, where each one breaks, and how to tell which fits the page in front of you. If you work with manuscripts or pre-modern print, the label on the tool matters far less than whether the model has seen material like yours; getting that wrong can cost you weeks before you notice the errors are systematic.

OCR (optical character recognition) and HTR (handwritten text recognition) both turn images of text into machine-readable characters, but they were built on different assumptions and break in different places. Classical OCR was engineered to read clean, modern print by segmenting the page into individual glyphs and matching each against a model of expected letterforms. HTR was designed for handwriting, where there are no fixed letterforms to match, so it reads a whole line as a sequence instead. The distinction matters most at the edges: cursive script, and pre-modern print, are exactly where a tool built on the wrong assumption quietly fails.

That is the short answer. The longer one is worth having, because the labels have grown slippery — and because choosing the wrong tool for a given page can cost you weeks before you notice the errors are systematic rather than incidental.

Two Different Bets About the Page

The cleanest way to understand the difference is mechanistically, not by which tool has which label on the box.

Classical OCR assumes reproducible shapes

Printed type is, by design, repeated: the same letter struck from the same sort looks the same down the page. Classical OCR exploits this. It typically binarises the image, segments it into lines, words, and individual glyphs — often by connected-component analysis — and classifies each isolated glyph against a model of expected letterforms. Character segmentation, as the survey literature has long noted, is the critical and fragile step. On clean modern print the approach is very good: general-purpose engines reach 95–99%+ character accuracy on well-scanned Latin-alphabet machine print, fast and cheap.

HTR assumes variable shapes

Handwriting has no stable font. The same scribe forms the same letter differently twice in a line; letters connect; ascenders collide with the line above. There are no clean glyph boundaries to segment. Modern HTR therefore abandons per-character segmentation and treats the line image as a single sequence: a convolutional and bidirectional-LSTM backbone produces a feature sequence, and either a CTC output layer (Graves, 2006) or an attention-based encoder–decoder aligns those features to characters. Because nothing forces the model to commit to where one letter ends and the next begins, it copes with connected and cursive script that segmentation-first OCR cannot.

So the difference is not "one reads print, one reads handwriting" as a matter of branding. It is a difference in what the system bets about the page: fixed, separable glyphs versus a continuous, variable stroke. That bet is the whole story, and it explains where each approach fails.

A fuller account of how that sequence model runs — segmentation, recognition, and why accuracy depends on how well the model matches your specific hand — is worth reading if you want the internals; the HTR pipeline from image to export is a separate subject in its own right. Here the goal is narrower: to know which bet fits your material.

Where the Labels Stop Describing the Tools

Two complications have blurred the line, and both matter in practice.

The OCR/HTR line is now largely an architectural fiction

The same Transformer-based models — image encoder plus text decoder — read both print and handwriting from a single checkpoint, dispensing with explicit line segmentation entirely. The field has coined a deliberately neutral umbrella term, Automatic Text Recognition (ATR), adopted by DARIAH-Campus, Teklia, OCR-D and READ-COOP, precisely because "OCR" and "HTR" no longer name mutually exclusive machines. A modern recognizer that reads a secretary-hand will and a printed pamphlet is not switching disciplines; it is applying one sequence model to two kinds of page. The practical lesson: describe a tool by what it demonstrably does on your material, not by the acronym in its marketing.

A third term muddies things further

ICR (intelligent character recognition) is a vendor coinage — you will see it from Adobe and ABBYY — for template-based recognition with a layer of adaptive learning bolted on, aimed mostly at hand-printed fields in forms. It is best understood as an extension of classical OCR, not a separate discipline. If a page you care about is a centuries-old cursive letter rather than a boxed-field intake form, ICR is not the category you are shopping in.

The Place the Distinction Actually Bites: Historical Print

Here is the trap that catches most people, because it sits exactly where the labels mislead. The assumption is that OCR "can read anything printed." It cannot — not reliably — and the reason is instructive.

General-purpose OCR was trained on a distribution: clean, high-contrast, modern founts with regular letterforms and predictable spacing. Historical print violates nearly every term of that assumption:

  • Typography the model has never seen. Blackletter and Fraktur; the long s (ſ) read as f; ligatures (ct, st, æ, œ) split or dropped; swash and variant sorts. The catalogue of common Fraktur OCR errors runs long — f/ſ, a/u/n, c/e/o confusions, and systematic false "corrections" such as eigenthümlich silently modernised to eigentlich.
  • The physical page. Uneven inking, type bite, show-through from the verso, foxing, warped gutters — noise a glyph classifier reads as character evidence.
  • Typographic abbreviation. Early printers carried the scribal repertoire into type: the macron or titulus for an omitted nasal, brevigraphs, contraction marks. Conventional OCR has no representation for a mark that stands for absent letters, so it drops it, mangles it, or normalizes it away.
  • Orthography that is not an error. Archaic spelling and u/v, i/j interchange — which OCR post-processing tends to "fix," destroying exactly the evidence a textual scholar came for.

The measured cost is real. On the OCR-D ground-truth corpus of German and Latin printings from 1500–1835, pre-trained mixed models manage a character recognition rate of only 91–98%, with the worst results on the earliest material — and that is with models aimed at historical print, not general-purpose engines run blind.

The established remedy in the OCR-for-print world has been to train a book- or font-specific model on curated ground truth. It works: Calamari reaches roughly 5.5–8.8% CER on incunabula with as little as 50 lines of book-specific ground truth, and OCR4all reports font-face-specific models at ≥99.97% accuracy on early-modern Latin and German prints. The price is the ground-truth labour and the training step — reasonable for a single well-defined corpus, less so when your material is heterogeneous.

Cursive and Archival Hands: The Other Hard Case

The mirror image of the historical-print problem is manuscript. This is HTR's home ground, but "handwriting" is not one problem. Accuracy swings hard by hand, period, language, and image quality — and the published record is uneven. German Kurrent and Sütterlin are comparatively well served: Transkribus's Kurrent/Sütterlin/Fraktur model reports 5.40% CER across the 17th–20th centuries. But English secretary hand, French notarial cursive, and Dutch and Spanish archival hands have far thinner published benchmarks; what exists tends to be one-off case reports rather than systematic evaluation.

The dominant specialist workflow answers this the way the print projects do: with fine-tuning. eScriptorium can start text-recognition fine-tuning from as few as 2–3 corrected pages; Transkribus recommends at least 25 pages of training material and tells users to aim for CER ≤10% to be "accurate enough for search purposes." That is the standing bargain of specialist HTR: high accuracy in exchange for ground-truth labour, per corpus, before you can begin.

Reading the Accuracy Numbers Without Being Misled

Because this whole comparison is usually settled by citing an error rate, it is worth being precise about what an error rate is.

CER (character error rate) is the edit distance between the ground truth and the transcription — substitutions, deletions, insertions — divided by the number of characters in the reference. WER (word error rate) is the word-level analogue, and is usually larger, because a single wrong character fails the whole word.

Two cautions follow, and neither is optional.

First, a CER number is meaningless without its material. The same engine that posts low single-digit CER on modern print climbs into the teens on historical print, and handwriting figures move with the hand, the period, the language, the scan quality, and how much fine-tuning went in. A figure quoted without its corpus, language, period, model version, and ground-truth budget tells you almost nothing.

Second, no standardised cross-tool benchmark on a common historical test set exists. Vendor figures come from different corpora with different error definitions; widely cited analyst and invoice benchmarks are not peer-reviewed. The convenient thresholds — CER ≤5% excellent, 5–10% usable for search, 10–20% correction-heavy, over 20% generally not publishable — are practical convention from ICDAR and Transkribus practice, not codified standards. Treat them as heuristics.

When the Distinction Matters — and When It Stops Mattering

For most working researchers the decision reduces to a single question: is the shape on your page reproducible or variable? Reproducible, modern, clean print — invoices, contemporary books, forms — is general-purpose OCR territory, and the mainstream engines are excellent, fast, and cheap there. Anything else — cursive hands, and pre-modern print with its long s, ligatures, and typographic abbreviation — is where a tool built on the segmentation-and-match assumption degrades, and where you need a model built for the material.

The convergence to ATR is what changes the calculus. A single sequence model can read both a printed early-modern pamphlet and the handwritten marginalia beside it, which is convenient — but only if that model was trained on images of historical documents rather than on modern print. That is the distinction worth carrying forward: not OCR versus HTR as rival disciplines, but whether the recognizer has actually seen material like yours.

This is the specific gap Leo is built to close. Its ATR-1 model reads Latin-script material — whatever the language on the page, English wills, French notarial records, Dutch registers, German parish books, or the printed books and pamphlets alongside them — without a per-corpus training step, because it is zero-shot rather than fine-tune-first. On a randomized 97-image sample of early-modern English manuscripts from the Folger Shakespeare Library, ATR-1 scored roughly 5% CER at release — 61% fewer errors than the next-best model (Transkribus/Text Titan I at about 13%, and general LLMs such as Claude Opus at 23.3% and GPT-4.1 at 56.7%). Two things follow from how it is trained. It handles both print and manuscript, so the historical-print problem and the cursive problem are one workflow rather than two. And it is built to transcribe what is on the page — the long s stays a long s, the macron is not silently resolved, the archaic spelling survives — rather than smoothing the text into modern, plausible prose.

That last point is the real safety argument, and it is where general chatbots are most dangerous on this work. A specialist recognizer, when it errs, tends to err on a character or a word — visible, recoverable mistakes. A general LLM leaning on a downsampled image errs by producing fluent, confident, wholly invented text that reads perfectly and is wrong. The plausible error is the expensive one, because you may never catch it. Which language a tool truly handles is a separate question again — one that turns on script, language, and hand rather than a supported-languages count.

The Practical Takeaway

Stop asking whether a tool "is OCR" or "is HTR." The categories have converged, the labels mislead at the edges, and the marketing term will not tell you what happens to your actual page. Ask three questions instead: Is the shape reproducible or variable? Has the model seen material from my period, script, and hand? And when it makes a mistake, is that mistake the kind I can see and fix, or the kind that hides in fluent prose?

Answer those honestly and the tool choice usually makes itself — and, just as important, you will read the accuracy numbers you are quoted with the skepticism they deserve. The century, the hand, and the ink on your particular page decide more than any headline figure ever will.

Frequently Asked Questions

What is the difference between HTR and OCR?

HTR (handwritten text recognition) and OCR (optical character recognition) both turn images of text into machine-readable characters, but they make different bets about the page. Classical OCR assumes reproducible shapes: it segments the page into individual glyphs and matches each against a model of expected letterforms, which works well on clean modern print. HTR assumes variable shapes, so it abandons per-character segmentation and reads a whole line as a single sequence — coping with cursive and connected script that segmentation-first OCR cannot. The distinction matters most at the edges: cursive script and pre-modern print, where a tool built on the wrong assumption quietly fails.

Can OCR read historical printed documents?

Not reliably. General-purpose OCR was trained on clean, high-contrast, modern founts with regular letterforms, and historical print violates nearly every part of that assumption. Blackletter and Fraktur, the long s read as f, split or dropped ligatures, uneven inking, show-through, and typographic abbreviations like the macron all trip up a glyph classifier. It also tends to "fix" archaic spelling and u/v, i/j interchange, destroying the exact evidence a textual scholar came for. Even models aimed at historical print manage only 91–98% character recognition on early German and Latin printings, with the worst results on the earliest material.

What is Automatic Text Recognition (ATR)?

Automatic Text Recognition (ATR) is a neutral umbrella term for recognizers that read both print and handwriting from a single model, adopted by DARIAH-Campus, Teklia, OCR-D and READ-COOP. It reflects that "OCR" and "HTR" no longer name mutually exclusive machines: the same Transformer-based models — an image encoder plus a text decoder — read a secretary-hand will and a printed pamphlet from one checkpoint, without explicit line segmentation. The practical lesson is to describe a tool by what it demonstrably does on your own material, not by the acronym in its marketing. A modern recognizer applying one sequence model to two kinds of page is not switching disciplines.

What is a good CER for historical document transcription?

CER (character error rate) is the edit distance between ground truth and transcription, divided by the number of characters in the reference. Practical convention from ICDAR and Transkribus treats CER ≤5% as excellent, 5–10% as usable for search, 10–20% as correction-heavy, and over 20% as generally not publishable — but these are heuristics, not codified standards. A CER number is meaningless without its material: the same engine posts low single-digit CER on modern print and climbs into the teens on historical print, and handwriting figures move with the hand, period, language, scan quality, and how much fine-tuning went in.

Why do general AI chatbots produce dangerous errors on historical documents?

General LLMs are most dangerous on manuscript and historical-print work because of how they fail. A specialist recognizer, when it errs, tends to err on a character or a word — visible, recoverable mistakes. A general LLM leaning on a downsampled image errs by producing fluent, confident, wholly invented text that reads perfectly and is wrong. The plausible error is the expensive one, because you may never catch it. General chatbots also tend to smooth text into modern, plausible prose — silently resolving a macron or modernising archaic spelling — rather than transcribing what is actually on the page.

© 2026 Leo Technologies Limited. All rights reserved