Amazon Textract Handwriting Recognition on Historical Records: What It Reads, and Where the Pipeline Breaks

This is a working assessment of Amazon Textract handwriting support for archives holding manuscript record series — what AWS documents, what it does not, and where a Textract-based pipeline quietly fails on centuries-old hands. If you are deciding which series to route where, and how to prove later that your catalogue text matches the record on the shelf, this is the ground to stand on.

Amazon Textract does recognize handwriting. Its documented handwriting support is English only, and AWS publishes no accuracy figure for historical hands. Within its documented envelope — modern forms, tables, invoices, IDs, and printed text — it is fast, inexpensive, and dependable. On an eighteenth-century deed book or a nineteenth-century docket series, the failure mode is not an error message. It is a non-empty response that looks like a transcription and is quietly incomplete. If you are routing manuscript-heavy record series, you need a recognizer trained on historical documents and a validation step that measures coverage as well as characters.

That is the short version. The longer version matters more, because most archives evaluating Textract are not choosing between it and nothing. They are choosing which series to send where, and how to defend the result afterwards.

What Textract actually is, and what it is engineered for

Amazon Textract is AWS's machine-learning document-analysis service. It extracts printed text, handwriting, layout elements, and structured data from images and PDFs, and it goes beyond raw character recognition to identify and extract specific data from documents.

Its API surface is the clearest statement of intent. `DetectDocumentText` is the raw text path, returning lines and words. `AnalyzeDocument` adds feature types — `TABLES | FORMS | QUERIES | SIGNATURES | LAYOUT` — and returns block relationships between them. Beyond that sit three purpose-built paths: `AnalyzeExpense` for invoices and receipts, `AnalyzeID` for driver's licences and passports, and an Analyze Lending workflow for mortgage loan packages. Synchronous operations serve single-page, latency-sensitive work; `StartDocumentTextDetection` and `StartDocumentAnalysis` handle multipage material asynchronously from S3.

Read that taxonomy honestly and it describes a business-document service: intake forms, claims, tax filings, employment applications, loan files. That is a substantial engineering achievement, and for a records office that also processes modern administrative paperwork, it is a good fit. What it is not is a published claim that the service was trained or benchmarked on court files from the 1780s or grantor indexes from the 1860s.

Operationally, the limits are documented and worth knowing before you design ingestion: synchronous input is capped at 10 MB, asynchronous PDF input can reach 500 MB, and an asynchronous job ID stays valid for seven days. Those numbers describe how the service runs, not how well it reads.

The handwriting announcement, read carefully

AWS announced handwriting recognition on 13 November 2020. The announcement is specific: support for handwriting in English documents, alongside expanded printed-text language support for Spanish, Portuguese, French, German, and Italian. It notes that English printed and handwritten text can be free-form or embedded in tables and forms, and describes results as carrying high confidence scores.

The current AWS FAQ maintains that split. Printed text, forms, and tables are listed for English, German, French, Spanish, Italian, and Portuguese; handwriting, Queries processing, invoices, receipts, and identity documents are English only. The same FAQ describes handwriting support as covering the Standard English alphabet and ASCII symbols.

For archives, two consequences follow. Neither is a criticism of AWS. It is simply what the documentation says.

First, script and language are not the same axis, and Textract's documentation is organized by language. A French notarial minute, a Dutch baptismal register, or a German-language probate file is written in the Latin alphabet, but none of them is thereby documented as supported handwriting. There is no Dutch entry at all in the handwriting list. If your holdings include vernacular manuscript series in any language other than English, the documentation does not cover you. This distinction is worth settling before any procurement conversation; it is the same confusion that makes language and script coverage claims in HTR easy to misread across the whole tool category.

Second, "English handwriting" in a service designed around intake forms means legible modern printing and cursive on a form field. It does not establish performance on connected secretary hand, on clerical abbreviation, on archaic orthography, on interlineation and marginal insertion, or on a page where the ink has bled through from the verso. No dataset-named CER or WER result for Textract on historical handwriting has been published — not for deed books, not for court files, not for wills or registers. That absence is not proof of failure. It is a reason not to accept a general capability statement as an archive-specific claim.

Where the pipeline actually breaks

The dangerous case is not the page Textract refuses. It is the page it accepts.

A historical manuscript page can produce a plausible-looking partial result: lines missed entirely, adjacent lines merged, reading order scrambled across a two-column register, marginalia dropped, and character substitutions inside names and figures. The API returns 200. The JSON is well-formed. Downstream, your indexer ingests it and your catalogue reports the series as full-text searchable. This risk follows from how recognition pipelines work, as documented in general OCR and HTR research; it is not a measured Textract-specific rate on deed books. It is, though, exactly the risk a coverage-blind pipeline is built not to notice.

Three pressure points deserve naming.

Line and region coverage

Traditional recognition pipelines depended heavily on preprocessing and character segmentation. Modern HTR more commonly uses end-to-end approaches — CTC, sequence-to-sequence, attention, or hybrids — that learn line-level visual-to-text mappings, which suits connected cursive and wandering baselines better. Historical handwritten recognition carries its own distinct challenges: transcription cost, variety of writing styles, abbreviations, symbols, and reproduction quality. If a segmentation step never proposes a line, no recognizer downstream of it can transcribe that line. Your quality metric therefore has to include recall of lines and regions, not only character accuracy on the lines that were found.

Confidence as a certification

Textract returns a confidence value from 0 to 100 for each element, plus bounding-box geometry, so you can set custom rules to flag anything below a threshold. That is useful for triage. It is not a fidelity guarantee. Calibration is the task of tuning confidence scores to match the underlying probability of a correct prediction, and Amazon's own researchers report that text-recognition models tend toward overconfidence, leading users to overestimate trust in the predicted outcome. The same work finds word-level calibration more suitable than naïve character-level calibration for sequential decoding. On out-of-distribution historical pages, treat confidence as a queue-ordering signal for human review. Do not let it certify a legal name, a date, a parcel description, or a docket number.

Mixed print-and-manuscript pages

The pre-printed form filled in by hand — the deed-book template, the ruled register, the docket sheet with printed headings — is among the hardest layout classes in the government-records inventory, and it is where a system's design assumptions show most clearly. A recognizer built around printed structure will tend to favour that structure. Honesty requires saying that this class is difficult for specialist tools too, including ours. It is not a weakness unique to general OCR.

Reading the accuracy literature without being misled by it

There is a strong temptation, mid-procurement, to find one number and use it. Resist it.

Consider the spread in a single 2025 handwritten-text benchmark. On IAM (modern English handwriting) it reports GPT-4o-mini at 1.71% CER, and on RIMES (modern French) GPT-4o at 1.69% CER, in reproduced zero-shot experiments; the same paper's reproduced Transkribus Text Titan I results are 9.13% and 10.71% CER on those sets. Move to historical material in the same benchmark and that reproduced model gives 7.07% CER on Bentham, 14.40% on ICDAR2017, and 40.63% CER with 64.28% WER on READ2016. Those are not Textract results, they are not a controlled comparison, and — this is the part that matters for a records office — the general-model figures come from modern, clean, single-language handwriting datasets, one corpus at a time, with the transcription still requiring verification before anything is published or indexed. A separate 2025 assessment of historical HTR reports Transkribus validation CERs around 4% against out-of-distribution results in the 8–25% CER and 15–50% WER range. The lesson across all of it is dataset and model dependence: the number that describes your collection is the number you measure on your collection.

CER is normalized Levenshtein distance — deletions plus insertions plus substitutions, divided by reference characters. WER applies the same edit distance at word level. They measure different units and are not interchangeable, and both aggregate away the errors you most care about. A 4% CER that concentrates its errors in surnames and section numbers is worse, for a land-registry office, than a 7% CER that scatters them through boilerplate. If you want a defensible figure, report collection-specific CER and WER alongside line and region recall, and weight errors in names, dates, boundary calls, and docket identifiers separately. Our fuller treatment of what transcription accuracy metrics actually measure works through why confidence scores and vendor benchmarks make poor substitutes for local ground truth.

The routing decision, stated plainly

If you already run on AWS, the sensible design is hybrid, and it follows from the evidence rather than from any vendor's preference. Keep Textract for what its API taxonomy tells you it is for: modern print, structured forms, tables, signatures, IDs, and the administrative paperwork your office generates today. Route manuscript-heavy series — the bound deed books, the pre-1900 case files, the probate and naturalization runs — to a recognizer built for historical hands. Then validate the handoff with stratified sampling rather than relying on a confidence threshold to route pages for you.

AWS integration solves ingestion, orchestration, and storage. What it does not solve is the recognition domain shift, and no amount of pipeline elegance closes that gap.

The same logic applies to the other default: crowdsourced transcription. The National Archives' Citizen Archivist missions and the Library of Congress's By the People programme, which has added OCR to its volunteer workflow, produce careful work — but volume is bounded by volunteer availability, which is precisely the constraint an unindexed hundred-thousand-page series exposes. Machine transcription with targeted human review of high-stakes fields is the throughput path. Our guide to court record transcription at scale sets out how to structure that review, and the deed transcription guide covers the chain-of-title case specifically.

Where Leo fits in that routing

Leo occupies one stage of this pipeline: recognition and the workspace around it. It begins at upload — it does not capture or scan — and it does not do IIIF, OAIS packaging, or EAD/METS/PREMIS. What it does is read the page.

Its engine, ATR-1, is a Transformer trained on images of historical documents, and its scope is defined by the writing system rather than the language: any language written in the Latin alphabet, handwritten or printed, from roughly the past five hundred years. That is where it diverges from Textract's documented envelope. English wills, French notarial records, Dutch registers, German parish books, Spanish and Italian material — all in scope, with performance strongest in English and strong across the other major European languages recorded in that alphabet. Non-Latin scripts — Greek, Cyrillic, Hebrew, Arabic, Indic and East Asian — are out of scope. It runs zero-shot, with no per-office model training and no segmentation step to configure. And it transcribes what is on the page: strikethroughs, insertions, marginalia, abbreviation marks, and archaic spelling survive rather than being silently normalized into modern prose. Translation, where you need it, is a separate one-click Transformation that writes to a new tab and leaves the base transcription untouched.

On the accuracy question, the only figure we publish is a manuscript benchmark, and we publish the workings. 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% character error rate against Transkribus/Text Titan I at about 13%, Claude Opus at 23.3%, Gemini 2.5 Pro at 24.8%, and GPT-4.1 at 56.7% — 61% fewer errors than the next-best model, with the full comparison sheet here. That is one corpus and one language; it is a directional result, not a claim about your holdings.

Two limits stated in the same breath, because they bear on government records specifically. Pages where dominant printed structure carries dense handwriting — pre-printed ledger and deed-book forms — are our known weak spot, and complex tabular layouts vary in quality. Where output looks wrong, ATR-1's failure detection hides it, retries automatically, and refunds the credit if it cannot succeed; errors that do get through are the recoverable kind, a wrong character or word checkable against the image displayed beside the text, rather than a fluent fabrication. That asymmetry is the whole argument for a specialist recognizer over a general model on a legally consequential series.

Sample your own material before you commit — a hundred pages, stratified by hand and period, keyed against a reference transcription. Historical print is in scope for the product; note only that printed material is not eligible for our transcription grant, so it belongs on the free tier or a paid plan.

What a defensible record trail looks like

Whatever recognizer you route to, the obligations do not change. Keep the image beside the text, permanently and in public view, so any reader can check the transcription against the record. Measure coverage as well as accuracy, and publish the method you used to measure it. Weight review toward the fields that carry legal or financial consequence. Record which model and which version produced each transcription and when, because models change and a catalogue that cannot say what read a page cannot defend it later.

None of that is a technology problem. It is the same discipline archivists have applied to calendars, indexes, and published editions for a century: state what you did, show the source, and let the reader see where your reading came from. Machine transcription changes the throughput, not the standard of proof — and the offices that get this right will be the ones that treated the recognizer as one documented step in a described process, rather than as an answer.

Frequently Asked Questions

Does Amazon Textract handwriting recognition work on historical documents?

Amazon Textract does recognize handwriting, but its documented handwriting support is English only, and AWS publishes no accuracy figure for historical hands. The service is engineered for modern business documents — forms, tables, invoices, IDs, and printed text — and its API taxonomy reflects that. On an eighteenth-century deed book or a nineteenth-century docket series, the usual failure is not an error message but a well-formed response that looks like a transcription and is quietly incomplete: lines missed, reading order scrambled, marginalia dropped. For manuscript-heavy series, use a recognizer trained on historical documents and validate coverage as well as characters.

What languages does Amazon Textract support for handwriting?

English only. AWS lists printed text, forms, and tables for English, German, French, Spanish, Italian, and Portuguese, but handwriting, Queries processing, invoices, receipts, and identity documents are English only, covering the standard English alphabet and ASCII symbols. This matters for archives because script and language are different axes. A French notarial minute, a Dutch baptismal register, or a German-language probate file is written in the Latin alphabet, yet none is documented as supported handwriting — there is no Dutch entry in the handwriting list at all.

Can I trust Textract confidence scores to certify a transcription?

No. Textract returns a confidence value from 0 to 100 per element plus bounding-box geometry, and you can set rules to flag anything below a threshold — useful for triage, not a fidelity guarantee. Amazon's own researchers report that text-recognition models tend toward overconfidence, which leads users to overestimate trust in the predicted outcome; the same work finds word-level calibration more suitable than naïve character-level calibration. On out-of-distribution historical pages, treat confidence as a queue-ordering signal for human review, never as certification of a legal name, date, parcel description, or docket number.

Should I use Textract or a specialist HTR tool for archival records?

If you already run on AWS, use both. Keep Textract for what its API is built for: modern print, structured forms, tables, signatures, IDs, and today's administrative paperwork. Route manuscript-heavy series — bound deed books, pre-1900 case files, probate and naturalization runs — to a recognizer built for historical hands. Then validate the handoff with stratified sampling rather than letting a confidence threshold route pages for you. AWS integration solves ingestion, orchestration, and storage; it does not solve the recognition domain shift.

How accurate is Leo's ATR-1 on historical handwriting compared with other models?

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% character error rate, against about 13% for Transkribus/Text Titan I, 23.3% for Claude Opus, 24.8% for Gemini 2.5 Pro, and 56.7% for GPT-4.1 — 61% fewer errors than the next-best model. That is one corpus and one language: a directional result, not a claim about your holdings. Known weak spots remain pre-printed ledger and deed-book forms where dominant printed structure carries dense handwriting, and complex tabular layouts. Sample your own material before committing.