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

The difference between HTR and OCR for historical documents: how each reads a page, why conventional OCR struggles with old print as well as handwriting, and where ATR models such as Leo's ATR-1 fit.

Leo Team

July 14, 2026

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

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.

HTR vs OCR: The Short Answer

HTR vs OCR (or OCR vs HTR, as it is often searched) comes down to what each was built to read. OCR (optical character recognition) was built for machine print: it splits the page into individual letters and matches each against the typefaces it was trained on. HTR (handwritten text recognition) was built for handwriting, where letters join and vary, so it reads a whole line as one sequence and works out each letter from context.

For historical documents, though, the line that matters is modern and regular versus historical and irregular, not print versus handwriting. Conventional OCR struggles with old print too: the long s, ligatures, blackletter and archaic spelling trip it even when a person reads the page easily. The tools that do best on historical material are a third kind, automatic text recognition (ATR) models that read print and handwriting with one model. Leo's ATR-1 is one: tuned for historical documents, it reads a secretary-hand will and an early-modern pamphlet alike, and keeps the spelling on the page.

  • Conventional OCR is built for modern machine print and reads clean modern books, forms and invoices well. It stumbles on cursive, the long s, ligatures, Fraktur, archaic spelling and multi-column reading order.
  • HTR is built for handwriting and reads hands like the ones it was trained on, but not hands far from its training data
  • Specialist ATR models, such as Leo's ATR-1, read historical handwriting and print in one model: manuscript hands and early-modern print, with no per-collection training

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. This comparison sits in our handwritten text recognition section beside the wider practical guide.

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.

For the internals of that sequence model, see the HTR pipeline from image to export; for the wider orientation — what HTR is for, how to read CER, how to fold machine transcription into verified research — start from our practical guide to handwritten text recognition. 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. Leo's ATR-1, named for the term, is a model of this kind. 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 adaptive learning bolted on, aimed mostly at hand-printed fields in forms. It is an extension of classical OCR, not a separate discipline, and not the category to shop in for a centuries-old cursive letter.

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." On a clean nineteenth-century page it often can. On older print it struggles, and the reasons are instructive.

Conventional OCR was designed and trained for modern print, and its accuracy drops sharply on pre-1900 text even when a person can read the page easily. A British Library study of mass digitization concluded that pre-1900 material would be "fortunate to exceed 85%" character accuracy with fully automated OCR (Tanner, Muñoz & Ros, 2009). Ryan Cordell points out that OCR was developed mainly for typewritten, mid-twentieth-century business documents (Cordell, 2019), and Springmann and Lüdeling found that the engines' training on modern fonts is of very limited value for historical printings (Springmann & Lüdeling, 2017). Historical print breaks that assumption in specific, measurable ways:

  • The long s and other period letterforms. The long s (ſ) looks almost exactly like an f, and an engine that has never learned it reads "same" as "fame". Comparing the OCR of Eighteenth Century Collections Online with hand-keyed text, Hill and Hengchen found that words containing "f" made up 11% of the keyed corpus but 33.7% of the OCR'd one (Hill & Hengchen, 2019). Ligatures (ct, ſt, ff, ffl, æ, œ) are split or dropped, and swash and variant sorts confuse the classifier further.
  • Blackletter, Fraktur and mixed typefaces. Blackletter faces have letters that look alike (n/u, f/ſ, c/e), and pages that mix Fraktur, roman and italic are hardest of all. In the Europeana Newspapers evaluation of ABBYY FineReader on 600 pages, word-level success was 81.4% on roman type, 67.3% on Gothic and 64.0% on mixed pages (Pletschacher et al., 2015). 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. Our guide to Fraktur OCR sets out the letters to watch and the tools to use now.
  • Spelling and abbreviation that the dictionary "fixes". Conventional engines lean on dictionaries to settle uncertain characters, and historical spelling makes that backfire (Springmann & Lüdeling). In one early-modern corpus, about one word type in five per text is missing from a large modern word list (Baron & Rayson); when Australia's newspaper programme added a place-name dictionary to its engine, results got worse (Holley, 2009). Marks that stand for absent letters, such as the macron for an omitted nasal, are dropped or mangled, and archaic spelling and u/v, i/j interchange get "fixed" — destroying exactly the evidence a textual scholar came for.
  • The physical page, and the microfilm. Uneven inking, show-through and foxing are noise a glyph classifier reads as character evidence. And many large collections were OCR'd from microfilm: even with early-modern fonts trained, the eMOP project's final report put its OCR of Early English Books Online at about 68% correct (Mandell et al., 2015). Image quality sets a ceiling no engine can lift — see how to scan old documents for recognition.
  • Layout and reading order. OCR has to cut the page into regions and decide their order before it reads a word. On multi-column newspapers it can read most of the words and still put them in the wrong order: the Europeana evaluation found whole-page word accuracy of 20.2% when reading order counted, against 74.3% for the same output when it did not.

The measured cost is real even for tools aimed at old books. 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 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-specific models at ≥99.97% accuracy on early-modern Latin and German prints. The price is the ground-truth labour, per corpus.

Where vision-language models do better, and where they slip

The newer route is a model that reads the whole line in context instead of classifying glyphs one by one. In a 2026 benchmark of English print from 1612–1807, the best vision-language models made about one character error in forty, against about one in five for Tesseract (Clifford et al., 2026): the surrounding word tells the model that the tall s in "same" is not an f.

They fail differently, though, and less visibly. The same benchmark records models quietly modernizing spelling ("bloud" became "blood"), covering only part of a dense multi-column page, and occasionally declining a page altogether. Told to keep the original spelling, they became more faithful, which shows where the default pull lies. On historical print the question is no longer only "can it read the type?" but "will it keep what the type says?" Our guide to OCR for old books turns that question into a choice of model for each kind of book.

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, for instance, publishes a dedicated Kurrent/Sütterlin/Fraktur model); English secretary hand, French notarial cursive, and Dutch and Spanish archival hands have far thinner benchmarks. Modern joined-up writing and a 1620 secretary hand are different problems for a machine too, as we explain in can AI read cursive?

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. 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. Published thresholds vary, and some are generous. For reading and quoting you want a CER of about 2% or below; at 10%, roughly every second word contains an error. Yet 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%. Treat any threshold as a heuristic, and test any tool on a sample of your own pages before you trust its number.

When the Distinction Matters — and When It Stops Mattering

For most working researchers the decision reduces to one question: is the shape on your page reproducible or variable? Clean modern print — invoices, contemporary books, forms — is general-purpose OCR territory, and the mainstream engines are excellent there. Cursive hands and pre-modern print are where the segmentation-and-match assumption degrades, and where you need a model built for the material.

The convergence to ATR changes the calculus. One sequence model can read a printed early-modern pamphlet and the handwritten marginalia beside it — but only if it was trained on images of historical documents rather than modern print. The question worth carrying forward is whether the recognizer has seen material like yours.

This is the gap Leo's own model, ATR-1, is built to close. It is a Transformer tuned specifically for historical documents, and it reads handwriting and historical print with the same model: secretary and court hands, Gothic cursive and italic, and the early-modern founts, blackletter and long s that conventional OCR mishandles, in any language written in the Latin alphabet. It works zero-shot, with no training on your material. It is trained to transcribe what is on the page rather than normalize it: the long s stays a long s, the macron is not silently resolved, the archaic spelling survives. A modernized version, if you want one, runs as a separate Transformation in its own tab — the distinction our guide to historical language normalization explains.

ATR-1 also reads the image at high resolution, where general models downsample it, and checks its own output for failure patterns such as a line repeated over and over: suspect output is hidden, retried, and refunded if it still cannot succeed. The errors that get through tend to be recoverable — a wrong letter or word you check against the image beside the text.

Not every page needs that. In Leo's model library — one menu in the transcription window — ATR-1 is the default at 1 credit an image, with the large general models from OpenAI, Google Gemini and Anthropic Claude alongside for a second reading in its own tab. For a clean, legible 19th-century book or typescript you only want the text of, a small model such as GPT-6 Luna costs 0.02 credits an image, and the cloud OCR engines from Google, Microsoft and Amazon 0.04.

The safety argument is about how each tool errs. A specialist recognizer tends to err on a character or a word — visible, recoverable mistakes. A general model leaning on a downsampled image tends to err fluently: a modern spelling in place of the one on the page, a likelier word where the ink is faint. The plausible error is the expensive one, because you may never catch it. Can AI read old handwriting? separates those failure modes in more depth, and which language a tool truly handles 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 you will read the accuracy numbers you are quoted with the skepticism they deserve. The quickest test is your own page: run a few of your hardest images through ATR-1 on Leo's free plan, which includes 10 credits a month, and read the result against the image.

Frequently Asked Questions

HTR vs OCR: what is the difference?

OCR (optical character recognition) was built for machine print: it segments the page into glyphs and matches each against known letterforms. HTR (handwritten text recognition) was built for handwriting, reading a whole line as one sequence and inferring each letter from context. For historical documents the more useful line is modern versus historical, because conventional OCR also struggles with old print. Specialist ATR models, such as Leo's ATR-1, read both handwriting and historical print.

Can OCR read historical printed documents?

Often, on a clean nineteenth-century page; not reliably on older print. Conventional OCR was designed for modern type, and accuracy drops sharply on pre-1900 text even when a person reads it easily. The long s is read as f — in one study of eighteenth-century books, words containing "f" were 11% of a hand-keyed corpus but 33.7% of the OCR'd one. Blackletter scores lower, the built-in dictionary "corrects" historical spelling, and multi-column pages come out in the wrong order. Models built for historical documents, such as ATR-1, read this print and keep its spelling.

What is Automatic Text Recognition (ATR)?

Automatic Text Recognition (ATR) is a neutral umbrella term, adopted by DARIAH-Campus, Teklia, OCR-D and READ-COOP, for recognizers that read both print and handwriting from a single model. It reflects that "OCR" and "HTR" no longer name separate machines: the same Transformer-based models read a secretary-hand will and a printed pamphlet from one checkpoint. Leo's ATR-1 is a model of this kind, tuned for historical documents.

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. For reading and quoting, aim for about 2% or below. At 10%, roughly every second word contains an error: enough for keyword search, not for reading. Published 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%. 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?

Because of how they fail. A specialist recognizer tends to err on a character or a word — visible mistakes you can check against the image. A general model reading a downsampled image leans on what is probable, so its errors are fluent: a modern spelling in place of the one on the page, or a likelier word where the ink is faint. Nothing looks wrong, so you may never catch it. Leo's ATR-1 is trained to transcribe what is on the page rather than normalize it, and shows its transcription beside the image.

Is there one tool that reads both handwriting and historical print?

Yes. ATR models read both with a single model, and Leo's ATR-1 is built for exactly this mix: secretary and court hands, Gothic cursive, and early-modern print with its long s, ligatures and blackletter, in any language written in the Latin alphabet. It needs no training on your material and keeps the page's own spelling, at 1 credit an image.

Share this article