Claude reads form images and PDFs natively — no separate OCR (optical character recognition) stage is required for the model to see the page. The pipeline has four stations, and the reliability comes from treating extraction as untrusted until validation says otherwise.
Station 1: Ingest
Two input paths, with documented limits worth encoding as pre-flight checks in code:
| Input | Key limits |
|---|---|
| Images (JPEG, PNG, GIF, WebP) | 10 MB base64-encoded on the Claude API (5 MB on Bedrock and Google Cloud); max 8000×8000 px; token cost is ceil(width/28) × ceil(height/28) — about 1,296 tokens for a 1000×1000 image |
| PDFs | Up to 600 pages per request (100 when the context window is under 1M tokens); 32 MB total request size; standard PDFs only — no passwords or encryption. Each page costs text tokens (typically 1,500–3,000) plus image tokens |
Per-platform note: PDF and image input work on all platforms, but Bedrock and Google Cloud accept base64 only — no URL references or file IDs. The Files API, which lets you upload once and reference by file_id to keep request payloads small, is beta and available only on the Claude API, Claude Platform on AWS, and Foundry (Hosted-on-Anthropic deployments). Also place documents and images before your text instructions in the message — the docs note Claude performs best that way.
Station 2: Extract with a schema, not a prayer
Define the target record as a JSON schema and pass it via structured outputs (output_config with "type": "json_schema", objects set additionalProperties: false). This is generally available on the Claude API, Claude Platform on AWS, Bedrock, and Vertex AI, beta on Foundry. One prompt-design recommendation: give every field a description that says where on the form it lives and what to return when it's absent — an explicit null beats a guessed value.
Station 3: Validate in code
Structured outputs guarantee shape, not truth — and deliberately not every constraint. The docs list what schemas can't express: numeric bounds (minimum/maximum), string length limits, and recursive schemas all return 400 errors if used. So a code-level validation pass is a required station, not belt-and-suspenders:
- Range and format checks the schema couldn't carry (dates in plausible ranges, totals that sum, IDs that checksum).
- Cross-field consistency (line items vs. invoice total).
- Lookups against systems of record (does this vendor ID exist?).
- Response-level checks:
stop_reason: "refusal"arrives as HTTP 200 and may not match the schema;stop_reason: "max_tokens"output may be truncated — both go to exceptions, never to the database.
If you need page-level provenance ("this value came from page 3"), note a documented incompatibility: citations cannot be combined with structured outputs in one request (400 error), and scanned PDFs without extractable text aren't citable at all. The recommended workaround is two passes — extract structured data first, then a citation-enabled pass on the fields that need provenance — or simply asking for a page number as a schema field and verifying it in code.
Station 4: Route exceptions
Every document exits to exactly one of three lanes — a recommended discipline, not an API feature: auto-accept (all validations pass) writes to the target system with the model ID and trace ID attached; review (validation failures or self-reported low confidence) goes to a human queue showing the original page beside the extracted fields; reject (unreadable, wrong document type, or repeated failures) returns to the sender with a reason. Track the lane split per form type: a rising review rate is your earliest signal that a form layout changed.
Volume and cost
Backfilling an archive of forms is a batch job: the PDF docs explicitly recommend the Batch API (50% pricing) for high-volume PDF processing — available on the Claude API and Claude Platform on AWS; Bedrock and Vertex use their own cloud-native batch mechanisms instead. See batch analytics for the checkpointing pattern.
Where to go next
For accuracy measurement on extraction tasks, see extraction accuracy; for landing results in a database, extraction to DB; for the review-queue design, escalation to human.