Does Claude Have OCR?

No. Anthropic does not sell an OCR product. There is no Claude OCR API, no document endpoint, and no prebuilt invoice model. What Claude does have is vision: you send a PDF or an image to the standard Messages API and Claude reads it the same way it reads anything else, billed in ordinary input and output tokens. For most document work that is better than OCR, and for some jobs it is meaningfully worse. Here is the distinction that actually matters.

What Claude does instead of OCR

Traditional OCR is a transcription step. It converts pixels to characters and hands you back text with coordinates, and something else downstream has to decide which of those characters is the invoice total. Claude skips that split. It looks at the page and returns the answer you asked for, so a single call can go straight from a scanned invoice to structured JSON with vendor, date, totals and line items.

That means there is no OCR output to inspect. You cannot ask Claude for a raw character dump with bounding boxes the way you can ask AWS Textract or Google Document AI. If your pipeline needs per-word confidence scores or exact pixel positions, Claude does not produce them and no amount of prompting will change that. Anthropic does publish guidance for coordinate work, but it is approximate by its own description and not a substitute for a real OCR engine's geometry.

Does Claude AI have OCR capabilities?

It has the capability, not the product. Claude reads printed text, handwriting, tables, charts and screenshots through its vision support on every current model, and in practice it is very good at it, particularly on messy real-world documents where a classical OCR engine stumbles. What it lacks is the packaging: no per-page price, no OCR SKU, no schema guarantees, and no service level tied to transcription accuracy.

The practical test is what you need back. If you want an answer, Claude is a strong choice. If you want a transcript, you want an OCR engine.

How Claude reads a PDF, and what it costs

This is where teams get surprised. When you send a PDF, Claude converts each page to an image and also extracts the page's text layer, and it bills you for both. Anthropic puts the text side at 1,500 to 3,000 tokens per page depending on density, and the image side follows a published formula: an image costs ceil(width / 28) x ceil(height / 28) visual tokens, because Claude reads images in 28 by 28 pixel patches.

A US Letter page scanned at 150 DPI is 1,275 by 1,650 pixels, which works out to 46 by 59, or 2,714 visual tokens. Add the text layer and a single PDF invoice page costs roughly 4,200 to 5,700 input tokens before your own prompt. There are no additional PDF fees on top of that, which is simpler than the per-feature add-on pricing used by AWS and Azure, but it is not cheaper.

Those figures assume a 200 token prompt and 700 output tokens for structured JSON, and the Batch API halves all of them. The full derivation for every model, including the image-only path that skips the text layer, is on our Claude OCR pricing breakdown.

Can Claude read PDFs with images and scans?

Yes, and this is its real advantage. Because every page is rendered as an image regardless of whether it has a text layer, a scanned or photographed document is handled the same way a born-digital one is. There is no separate scanned-document code path to configure and no "this PDF has no text layer" failure mode. Claude also reads handwriting, stamps, and annotations that a text extraction library would miss entirely.

Practical limits are worth knowing before you build: 32 MB per request, 600 pages per request (dropping to 100 on models with a 200k token context window, which includes Claude Haiku 4.5), and standard PDFs only, with no password-protected or encrypted files.

Is Claude good at OCR compared with the alternatives?

On reading, yes. On price, no. Claude is the most expensive frontier reading layer in this market, and the reason is structural rather than a pricing decision. Google counts a document page as a flat 258 tokens no matter its dimensions. Claude counts the same page as 2,714 visual tokens because it tokenizes on a fine 28 pixel grid. That is roughly ten and a half times more image tokens for identical input, and it dominates the cost gap before per-token rates even come into it.

That fine grid is exactly why Claude does well on dense tables and degraded scans, so it is a deliberate tradeoff. Whether it is the right one depends entirely on your documents. Clean vendor PDFs do not need it. Crumpled delivery notes photographed on a warehouse floor very much do. We compared the options head to head in our writeup of the best LLM for invoice extraction.

Does Claude have an OCR API I can call directly?

You call the Messages API. Send a document content block with a base64 PDF or an image block with a JPEG, PNG, GIF or WebP, add a prompt describing the fields you want, and read the response. There is no endpoint named OCR, no separate authentication, and no document-specific rate limit. For repeated use of the same file, uploading once through the Files API and referencing it by ID keeps request payloads small.

The thing that catches people out is that none of the validation is done for you. A dedicated invoice API returns a typed schema with fields that either populated or did not. Claude returns whatever your prompt asked for, which means you own the retry logic, the schema validation, the arithmetic checks, and the reconciliation when line items do not sum to the total. That engineering is usually a larger cost than the tokens.

Which is cheaper, sending a PDF or an image?

An image, by roughly 19 to 36 percent. A PDF page bills for its text layer plus its rendered image; a PNG or JPEG bills for the image alone. Rasterizing pages before you send them cuts that text-layer line out of the bill entirely. The catch is that you give up the embedded text, which on a born-digital invoice is perfectly accurate and free of transcription error, so this trade only makes sense for scans.

The other lever is resolution. Because cost scales with pixel dimensions, scanning at 300 DPI instead of 150 roughly quadruples the image half of the bill with no accuracy gain on a clean document. Scan at 150, send images rather than PDFs, keep the output schema tight, and use the Batch API, and you can take a page from about $0.047 to about $0.0026.

When Claude is the wrong tool

Three cases. If you need per-character confidence scores or precise bounding boxes for a redaction or forms-mapping workflow, use a real OCR engine. If you are processing high volume and the documents are uniform, a flat per-page service such as Mistral OCR at $4 per 1,000 pages or a prebuilt invoice model will cost less and give you a stable schema. And if you need a guaranteed output shape for a downstream accounting system, a purpose-built extractor that validates totals and line items before handing them over will save you the reconciliation work.

Where Claude genuinely wins is the awkward middle: varied layouts, poor scan quality, documents that need judgment rather than transcription, and anything where the question is more interesting than the text. Once that data is out of the documents and into a table, querying it is a separate problem, and being able to ask questions of your data in plain English tends to matter more day to day than which model read the page.

The short answer

Claude has no OCR API and never has. It has vision, which for document extraction is usually the better primitive, because it collapses transcription and interpretation into one step. You pay for that in tokens rather than pages, you pay twice on PDFs, and you own all the validation that a dedicated document API would have done for you. If you want the numbers before you commit, start with the per-page cost math, and compare it against OpenAI and Gemini, which are priced on the same token basis.