The best handwriting OCR API in 2026: benchmarks, prices, and code

If you are reading this, you have probably already tried Tesseract on handwritten input and watched it return noise. That is not a Tesseract bug. It was built for printed text, and handwriting is a different problem. The question is what to use instead, and the answer depends on one variable more than any other: whether your documents are printed or handwritten.

We benchmarked the serious options on the same handwritten sample earlier this year for our nine-tool comparison. This post is the developer’s cut of that data: the same measured accuracy numbers, plus the things you actually compare when you are choosing an API, meaning price per 1,000 pages, structured output, integration effort, and working code.

The one-paragraph answer

If your documents are printed, use AWS Textract, Azure Document Intelligence, or Google Document AI. At list price their raw OCR costs about $1.50 per 1,000 pages, the accuracy on typed text is excellent, and nothing in this post will beat that. If your documents are handwritten, the same APIs return 8% to 23% Word Error Rates, and every recognition error flows downstream into your extracted fields. That is the gap a specialist API exists to close: Handwriting OCR returned 0.9% WER on the same sample, roughly one error per hundred words instead of one per ten.

The benchmark table, API edition

Accuracy numbers are from our published benchmark: one handwritten English prose page, 100 words, legible modern script, 300 DPI scan, identical input to every tool, Word Error Rate against a manually transcribed reference. Full protocol in the methodology section of the original post.

*Cloud prices are provider list prices as of July 2026, rounded, at entry-tier volume. Check the provider pricing pages before you build a forecast on them; they change and they discount at volume. LLM prices vary with image resolution and output length.

Two honest readings of that table. First, on raw price for printed text, the cloud APIs win by a factor of about 40 and you should use them for that job. Second, once handwriting and structure enter the picture, the price gap disappears (their extraction tiers cost $30 to $50 per 1,000 pages against $50 to $59 for the specialist) while the accuracy gap does not.

What the accuracy gap costs you in practice

WER compounds in a pipeline. A 10% WER on transcription does not mean your app is 90% fine. It means one word in ten is wrong, and if you are extracting fields, the wrong words land inside your extracted values: a “7” that became a “1” in a dosage field, a surname spelled three different ways across a batch, a date that parses but is not the date on the page. High-confidence wrong values are the expensive kind of error, because nothing flags them for review.

At 0.9% WER the output is usable as-is. On our sample that was a single short-word substitution in a hundred words. That difference is the entire economic case for a specialist API on handwritten input, and it is also why we tell people with printed documents to use the cheap cloud APIs instead. Accuracy you do not need is not worth paying for.

Using the Handwriting OCR API

The API is a plain REST interface with Bearer auth. Upload a document, get an ID back, receive results by webhook or polling, download in the format you need. File types: PDF, JPG, PNG, TIFF, HEIC, GIF, up to 20 MB. API access is included on every plan, including the free trial.

Upload a document for transcription:

curl -X POST "https://api.handwritingocr.com/v3/documents" \
     -H "Authorization: Bearer $HWOCR_TOKEN" \
     -H "Accept: application/json" \
     -F "file=@scan.pdf" \
     -F "action=transcribe" \
     -F "delete_after=3600"

The response is {"id": "abc123", "status": "queued"}. The delete_after parameter is the retention window in seconds (5 minutes to 14 days); the document and its results are removed automatically when it expires.

Fetch the result as JSON, or download it directly in another format by swapping the extension (.txt, .docx, .xlsx, .csv):

import requests, time

API = "https://api.handwritingocr.com/v3"
HEADERS = {"Authorization": f"Bearer {TOKEN}", "Accept": "application/json"}

doc = requests.post(
    f"{API}/documents",
    headers=HEADERS,
    files={"file": open("scan.pdf", "rb")},
    data={"action": "transcribe"},
).json()

while True:
    result = requests.get(f"{API}/documents/{doc['id']}", headers=HEADERS).json()
    if result["status"] == "processed":
        break
    time.sleep(5)

for page in result["results"]:
    print(page["page_number"], page["transcript"])

For production, skip the polling loop: pass a webhook_url with the upload (or set one globally in the dashboard) and the full JSON result is POSTed to you the moment processing finishes.

Structured extraction from handwritten documents

This is the part most pipelines actually need. Transcripts are an intermediate product; what you want is {"date_of_birth": "12/12/1994", "place": "Paris"}.

Custom Extractors work in two steps. You define an extractor once in the dashboard: name the fields, set their types, test it against a sample document. That gives you an extractor ID. Then every API upload with action=extractor runs your schema against the document:

curl -X POST "https://api.handwritingocr.com/v3/documents" \
     -H "Authorization: Bearer $HWOCR_TOKEN" \
     -H "Accept: application/json" \
     -F "file=@intake-form.jpg" \
     -F "action=extractor" \
     -F "extractor_id=Ks08XVPyMd"

The result is typed key-value pairs per page:

{
  "id": "gj8kAvDQ4p",
  "action": "extractor",
  "status": "processed",
  "results": [
    {
      "page_number": 1,
      "extractions": [
        [
          {"key": "date_of_birth", "name": "Date of birth", "type": "string", "value": "12/12/1994"},
          {"key": "place", "name": "Place", "type": "string", "value": "Paris"}
        ]
      ]
    }
  ]
}

There is also action=tables for extracting handwritten tables to structured rows and columns (downloadable as xlsx or csv), which covers the lab-notebook and field-log cases where the data is tabular rather than field-based.

The reason to care about extraction accuracy specifically: every extraction pipeline is only as good as the recognition underneath it. A form parser that misreads the handwriting hands you cleanly structured wrong answers. Running extraction on a 0.9% WER engine instead of a 10% one is the difference between spot-checking a batch and re-keying it.

One plan note so you are not surprised: transcription and the API are available on all plans, while Tables and Custom Extractors require the Pro plan ($59/month, 1,000 pages included) or above. Pay-as-you-go covers transcription only.

The rest of the field, honestly

AWS Textract. The right default if your stack is AWS-native and your documents are printed forms with occasional handwritten fields. S3-triggered async processing, IAM, and compliance tooling are mature. On fully handwritten input it sits around 10% WER and drops further on cursive. Its forms and queries features are priced around $50 per 1,000 pages, which is specialist territory without specialist handwriting accuracy.

Azure Document Intelligence. The strongest of the big three on our handwriting sample (8.67% WER) and the cleanest fit if you are already in the Microsoft ecosystem. Same caveat as Textract: the extraction tiers inherit the recognition layer’s handwriting errors.

Google Document AI. The weakest of the three on our sample (23.3% WER), with a reading-order failure that scrambled whole lines of prose. Fine for printed text, hard to recommend for handwriting.

GPT-5 and Claude vision APIs. Genuinely useful for prototypes: no new vendor, decent accuracy (11% to 14% WER), and you can prompt your way to any output shape. Three things stop us shipping them for document volume: silent correction (the model quietly substitutes a plausible word for the actual ink, which is worse than an obvious error because nothing looks wrong), degradation on multi-page documents, and the absence of document plumbing (retention controls, native formats, webhooks, per-document lifecycle). You end up building all of that yourself around a per-token bill.

Tesseract and the open-source engines. Free, excellent for printed text, and a hard no for handwriting. 95.4% WER means the output is noise. If the budget is zero and the input is handwritten, an LLM vision call is the realistic floor, not Tesseract.

Which API should you actually use?

Try it against your own documents

Benchmarks on our sample are a starting point; the number that matters is the error rate on your documents. Every account gets free trial credits with API access and no card required. Sign up at dashboard.handwritingocr.com/register, generate a token in Settings, and run your five hardest pages through the curl call above. If the output is clean, the rest of your corpus will be too. If something surprises you, send us a sample and we will tell you honestly whether we are the right tool for it.