https://txtfetch.com/docs/handwriting/
Does txtfetch read handwriting?
Not on the standard tier. Printed text, yes. Handwriting, no. Here is exactly what comes back, and where to send the handwritten pages instead.
The short answer
The standard tier runs Tesseract 5.5.2, using the tessdata_fast trained models, with the languages eng, osd shipped.
Source: terraform/lambda-layers/build/versions.env (versions.env: TESSERACT_VERSION, TESSDATA_REPO, TESSDATA_LANGS), accessed 2026-09-26.
Tesseract is built to read printed text. Its own project FAQ is direct about the rest:
"You can, but it won't work very well, as Tesseract is designed for printed text."
Source: Tesseract FAQ: printed vs. handwritten text, accessed 2026-09-26.
So a printed page comes back clean. A handwritten page, or a handwritten field on an otherwise printed page, comes back missing or garbled.
What comes back, case by case
The exact behaviour depends on the file type, and on whether a PDF already carries a text layer. txtfetch decides OCR for a PDF page by page. A page with 10 typed characters or fewer is read. A page with more is not. See the tested cases.
| Input | What comes back | Source |
|---|---|---|
| A photo or scan of handwriting only, no printed text | Little or nothing readable. Tesseract's printed-text models were not trained on handwriting. | Tesseract FAQ: printed vs. handwritten text (accessed 2026-09-26) |
| A printed form with handwritten answers (image file) | The printed labels come back clean. The handwritten entries come back missing or garbled. | Tesseract FAQ: printed vs. handwritten text (accessed 2026-09-26) |
| A scanned PDF with no text layer | Tesseract runs on the page image, the same as a plain image file. Printed text is readable; handwriting is not. | extract.js: the PDF OCR branchapi/extract/src/extract.js(accessed 2026-09-26) |
| A scanned PDF that already carries a text layer | OCR does not run on a page with more than 10 typed characters. txtfetch reads the existing text layer as-is, including whatever a scanner's own OCR already wrote for the handwritten fields. | Production API probe: POST /v1/extractmarketing/test/fixtures/images/README.md(accessed 2026-10-18) |
| A PDF with typed pages plus one scanned, handwritten page | OCR does run on the scanned page, because OCR works page by page. It runs when the page has 10 typed characters or fewer. Handwriting still reads poorly. A scanned page with a typed footer of more than 10 characters is not read at all. See /docs/images. | Production API probe: POST /v1/extractmarketing/test/fixtures/images/README.md(accessed 2026-10-18) |
| A born-digital PDF with a handwritten signature saved as an image | A picture on a typed page is not read by OCR, because the page has more than 10 typed characters. The signature image produces no text at all. See /docs/images. | Production API probe: POST /v1/extractmarketing/test/fixtures/images/README.md(accessed 2026-10-18) |
How to spot it in your own pipeline
A response never carries a confidence score, so a bad handwriting read looks like ordinary OCR output. Three signals catch it in practice.
- metadata.ocr is true, and metadata.chars is low. OCR ran, and it read almost nothing. That combination is the first thing to check when a batch of scans comes back thin. See every quality signal the response carries →
- The request fails with extraction_failed. OCR ran but found only whitespace. A page with only handwriting can return this error. It can also return garbled text with a success status. See the full fix for a PDF that extracts no text →
- You are not sure a scan is even OCR-ready. Check resolution, focus, and orientation in your browser before you send a single request. Check a scan's OCR-readiness free →
The premium tier
?quality=premium is sold as a tier, but it does not run today. VLM_ENABLED defaults to false, and no operator has switched the tier on in production. A premium request downgrades to the standard Tika path instead.
Nothing here claims a handwriting accuracy figure for the premium tier. There is no measurement to cite either way.
What to use instead
If handwriting is a real slice of your input, split the pipeline. Keep printed documents on txtfetch. Route only the handwritten pages to a vendor built for handwriting.
| Vendor | What they say about handwriting |
|---|---|
| Amazon Textract | "Amazon Textract can detect printed text and handwriting from the Standard English alphabet and ASCII symbols." Read the source → Compare with txtfetch → |
| Azure AI Document Intelligence (Read model) | "Extracts print and handwritten text from PDF documents and scanned images." The response marks handwritten text spans with an isHandwritten style flag. Handwriting support covers a set list of languages. Read the source → Compare with txtfetch → |
Frequently asked questions
- Can txtfetch read a handwritten signature?
- No, not reliably. A signature is a small, stylised handwriting sample, and Tesseract's printed-text models were not built to read it. If the page's other text has a real text layer already, txtfetch does not even attempt OCR on the signature image.
- Does block capital handwriting work better than cursive?
- It can read a little more of it, since block letters resemble print more closely than cursive does. Neither is reliable enough to depend on. Treat both as unsupported.
- Does this apply to non-English handwriting too?
- Yes. The standard tier ships English OCR only, and Tesseract's handwriting limits apply across every language it ships, not just English.
- Does the premium tier read handwriting?
- We have no measurement of premium handwriting accuracy, so we make no claim. The premium tier does not run today, so a premium request downgrades to the standard Tika path.
- Will txtfetch add handwriting support?
- No date is promised. If your pipeline needs handwriting today, route those pages to a vendor built for it, and keep everything else on txtfetch.
Watch it run, then take a key.
The playground replays a real recorded response for every sample document.
Open the playground →