Cost Optimization & FinOps

PDF Token Costs: What Document Uploads Actually Bill

A PDF page bills twice — once as extracted text, once as an image. Understanding that double charge is the key to estimating document-processing budgets that survive contact with the invoice.

Claude 3P 101 · Updated July 2026 · Unofficial guide

PDF support is available on every Claude surface — the Claude API, Claude Platform on AWS, Amazon Bedrock, Google Cloud, and Microsoft Foundry — and on all active models. There is no per-document or per-page fee; like vision, PDFs are billed purely as input tokens. The subtlety is how many tokens a page becomes, because each page is processed two ways at once.

The double charge per page

When Claude ingests a PDF, each page is converted to an image, and the page's extracted text is provided alongside it. You pay for both:

Text tokens. Typically 1,500–3,000 tokens per page depending on content density — a sparse slide deck sits at the low end, a dense legal contract at the high end.

Image tokens. The rendered page image is billed by the standard vision formula — ceil(width/28) × ceil(height/28) patches — so page resolution feeds directly into cost, exactly as it does for ordinary image inputs.

Rough sizing with real list prices: a 100-page contract at the documented 1,500–3,000 text tokens per page is 150k–300k text tokens before image tokens are added. At Claude Opus 4.8's $5/MTok input rate, that's $0.75–$1.50 of text-token cost per full read; on Claude Haiku 4.5 ($1/MTok), $0.15–$0.30. Re-send that document on every request in a workflow and the multiplier is your request count — which is why the caching and batch levers below matter more for PDFs than for almost any other input type.

Estimate before you commit: the token-counting endpoint (/v1/messages/count_tokens) accepts PDFs and is free, with its own generous rate limits. Counting a representative sample of your real documents beats any per-page rule of thumb.

Upload paths and their cost profile

A PDF reaches Claude as a document content block via three sources: a URL reference, inline base64, or a Files API file_id. Amazon Bedrock and Google Cloud support base64 only; the Files API is available on the Claude API, Claude Platform on AWS, and Microsoft Foundry (in beta there).

The Files API itself adds nothing to the bill: upload, list, metadata, download, and delete operations are all free, with limits of 500 MB per file and 500 GB per organization. You pay only when a message references the file — at which point its content bills as input tokens, same as base64. The win is operational: upload a big document once and reference it by ID instead of pushing megabytes of base64 through every request against the 32 MB request cap. Files persist until you delete them, so stale-document housekeeping is on you.

Structural limits that shape batching

A single request can include up to 600 PDF pages when the model's context window is 1M tokens, or 100 pages for 200k-context models like Claude Haiku 4.5. But dense PDFs can fill the context window before hitting the page limit — 600 pages × 3,000 text tokens is already 1.8M tokens on paper, well past even the 1M window. For long documents, split by chapter or section and process in parallel, or summarize progressively.

One platform-specific billing surprise: on Bedrock's Converse API, full visual PDF understanding (around 7,000 tokens for a 3-page sample) requires citations to be enabled; without citations it falls back to text-only extraction (around 1,000 tokens for the same 3 pages). That's both a capability difference and a 7x token difference for the same document — decide deliberately which mode your workload needs. Bedrock's InvokeModel API has no such constraint.

The two levers that tame PDF spend

Cache the document, query it many times. Document blocks are cacheable. A 200k-token filing cached once (5-minute write at 1.25x) then queried twenty times at the 0.1x read rate costs a fraction of twenty full re-reads — the arithmetic is in the cache break-even math. Official PDF guidance recommends exactly this for repeated analysis.

Batch the corpus. High-volume PDF processing is the canonical Message Batches workload: 50% off both input and output, and since batches can outlive a 5-minute cache, use the 1-hour cache TTL for shared context. On Bedrock and Vertex AI, Anthropic's Batches endpoint isn't available, but each cloud's native batch mechanism offers 50% batch pricing — see the batch discount for the platform map.

Also keep the vision-side habit: place PDFs before your text prompt in the request, and downsample embedded images if fidelity isn't needed — page image tokens follow pixels.

Where to go next

Pair this with image token costs for the pixel formula behind page images, and context strategy for keeping multi-turn document Q&A affordable.

Sources