Which OCR APIs Support Handwriting? AWS, Azure and Google Compared

The short answer: Amazon Textract, Azure Document Intelligence and Google Document AI all read handwriting, and none of them charges a handwriting surcharge. Handwriting is billed on the same meter as printed text, at $1.50 per 1,000 pages on all three. What separates them is language coverage. Azure reads printed text in more than 300 languages but handwriting in only 12. Amazon Textract reads print in six languages and handwriting in exactly one, English. Google supports handwriting but publishes no handwritten-language list at all.

That last point matters more than any accuracy claim you will read in a vendor comparison. If your handwritten forms are in English, all three will read them and your decision comes down to volume pricing and output structure. If they are not in English, most of the market disappears immediately. Below is the full comparison, taken from vendor documentation and checked on 25 July 2026.

Handwriting support by provider

Does handwriting OCR cost more than printed text OCR?

No. On all three major clouds, handwriting runs through the same basic OCR meter as printed text, with no separate handwriting product and no add-on to enable. Google's three premium OCR add-ons, billed at $6 per 1,000 pages, are Math OCR, checkbox extraction and font style detection. Handwriting is not among them; it is a default detection attribute of the base processor.

This surprises people who expect handwriting to be priced as a premium capability, and it quietly changes where the cost of a handwriting project actually lands. The API line item is identical. The money goes into review time, because handwriting produces more low-confidence reads than print, and somebody has to check them. When teams budget a handwriting pipeline purely on per-page API cost, that is the line they forget.

Does AWS Textract read handwriting?

Yes, but in English only. Amazon's own FAQ states that Textract "can detect printed text and handwriting from the Standard English alphabet and ASCII symbols", and separately that "Handwriting, Invoices and Receipts, Identity documents and Queries processing are in English only".

Textract extracts printed text, forms and tables in English, German, French, Spanish, Italian and Portuguese. So moving from printed text to handwriting narrows the service from six languages to one. If you are running a US-only workflow on English forms this is a non-issue. If you process Spanish-language intake forms anywhere in your business, Textract handles the typed ones and not the handwritten ones, which is an easy thing to discover far too late. The other request limits worth knowing before you commit are covered in our AWS Textract limits reference.

Does Azure Document Intelligence support handwriting?

Yes, and it currently has the widest published handwriting coverage of the three. The v4.0 GA Read and Layout models support 12 handwritten languages: English, Chinese Simplified, French, German, Italian, Thai, Japanese, Korean, Portuguese, Spanish, Russian and Arabic.

The catch is that the answer depends on which API version your code is pinned to. The v3.0 and v3.1 models support nine of those languages, without Russian, Thai or Arabic. And Microsoft states plainly in its language-support documentation that "Document Intelligence v2.1 does not support handwritten text extraction", so an application still calling v2.1 gets no handwriting at all.

That makes "does Azure read handwriting" a version question rather than a product question, and it is worth checking against your actual client library before you conclude the service cannot do something. Upgrading the API version is usually a smaller job than switching vendors. Azure's file size and page ceilings are a separate constraint, covered in our Azure Document Intelligence limits reference.

Does Google Document AI support handwriting?

Yes. Handwriting appears in Google's documentation as one of the default layout detection and extraction attributes of Enterprise Document OCR, alongside printed text. There is no handwriting add-on and no handwriting-specific processor to select.

What Google does not do is publish a handwritten-language table. AWS and Microsoft both tell you exactly which languages their handwriting recognition covers. Google's documentation offers only a tuning lever: "Language and handwriting hints: Improve accuracy by providing the OCR model a language or handwriting hint based on the known characteristics of your dataset."

This is a documentation gap rather than a capability judgement, and it should be read as exactly that. Google may well read handwriting in languages Azure does not. The practical consequence for procurement is that you cannot verify coverage for your language by reading the docs, so a Google handwriting decision has to be made from a test set of your own documents. Budget for that step rather than assuming a support matrix exists somewhere.

What about running handwriting on-premises?

Only one of the three offers a path. Azure Document Intelligence ships containers, and at v4.0 those containers cover the Read and Layout models. Read and Layout happen to be exactly the two models that perform handwriting recognition, so on-premises handwriting extraction is possible through Azure containers. What you do not get on-premises is handwriting inside the prebuilt Invoice, Receipt and ID models, which are not available in the v4.0 container set.

Amazon Textract and Google Document AI publish no on-premise deployment at all, so neither has an on-premise handwriting story. It is also worth noting that Azure's containers are not air-gapped; Microsoft's documentation requires them to connect out to Azure to send billing data.

Can large language models read handwriting instead?

They can, and none of the major model providers publishes a handwriting language restriction the way AWS and Microsoft do. That sounds like an advantage, and sometimes it is, particularly on messy or unusual layouts where a general vision model copes better than a dedicated OCR engine.

The trade-off is the one that applies to LLM-based OCR generally, and it bites hardest on handwriting: a language model returns fluent, plausible text whether or not it actually read the characters correctly, and it does not give you a per-value confidence score. On printed text that risk is small because the model rarely has to guess. On a smudged handwritten date field it is exactly the situation where a confident-sounding wrong answer is most likely and least detectable. If you go this route, build your own verification step, because the model will not flag its own uncertainty.

How to choose

Start with language, because it eliminates options faster than anything else. English-only handwriting means all three are candidates. Anything else means checking the Azure list first, then testing Google, and ruling out Textract.

Then look at what happens to a bad read. Handwriting produces more uncertain output than print, so the useful question is not "how accurate is it" but "what does the system do when it is not sure". An engine that returns a per-field confidence score lets you set a threshold and route everything below it to a person. An engine that returns text with no confidence signal pushes that judgement onto whoever consumes the data downstream, which usually means nobody makes it.

Finally, test on your own worst documents rather than a clean sample. Handwriting accuracy is enormously sample-dependent, which is why no vendor publishes a single handwriting accuracy figure and why you should be suspicious of any comparison that does. The forms your team finds hardest to type are the ones worth running through a trial. This is the same discipline that pays off with handwritten receipts attached to expense reports, where the practical move is usually to let software read the receipts and categorize the spend automatically rather than keying totals by hand.

If you want the full vendor matrix on one page, along with the 12 Azure handwritten languages listed out and the per-page rates in context, see our handwriting OCR reference. For how the three providers compare on cost once volume tiers kick in, which is a genuinely different question from the list rate, see OCR pricing per 1,000 pages.