Claude PDF Token Cost: What One Page Really Costs

The PDF support docs explain the mechanism: Claude converts each page into an image, extracts the page's text, and gives the model both. Then they hedge on cost. Text "typically uses 1,500 to 3,000 tokens per page", and the image follows the vision formula. Every third-party article I found repeats that range. Nobody had measured it, and "somewhere between 1,500 and 3,000" is a 2x spread when you're pricing a document pipeline, so I did.

On October 28, 2026 I ran 11 files through five models: Claude Opus 5.5, Sonnet 5.5 and Haiku 5.5 on the newer tokenizer, plus Sonnet 4.5 and Haiku 4.5 on the old one. Each file went in as a base64 document block with a one-word prompt, through Claude Code in headless mode, and I read the input tokens from the usage block. A run with no document gave the baseline, which I subtracted. The three 5.5 models returned identical counts.

The near-blank pages isolate the image cost: 10 pages with one short line each came to 15,586 tokens, so the page image is a flat ~1,560 tokens. Everything above that is the text layer. The math checks out almost exactly. The research paper is 15 pages × 1,560 = 23,400 image tokens, plus 15,140 tokens of extracted text, which predicts 38,540. The measured number was 38,354, within half a percent.

So the docs' range is roughly right for the total, but the split is the useful part. The paper's text was about 1,000 tokens per page and the W-9's about 2,200. The image never changed.

Takeaway: PDF tokens ≈ pages × 1,560 + the tokens of the extracted text. The image is a fixed tax on every page, even a blank one.

Page size, almost not at all. Same ten near-blank pages, four paper formats:

An 11 × 17 page has more than twice the area of Letter and costs 2% more. It looks like pages are rendered to a capped size before the model sees them, so a bigger sheet doesn't mean a bigger bill.

The model was more interesting. The vision docs say Claude 4.7 and later run a high-resolution tier where a large image can cost up to three times more. I expected PDF pages to get more expensive on Opus 5.5. They didn't. The image part measured 1,559 tokens per page on Opus 5.5 and 1,557 on Sonnet 4.5. The high-res tier doesn't touch PDF pages.

What does change is the text. Claude 4.7+ uses a newer tokenizer that the pricing page says produces about 30% more tokens for the same text. On the paper's extracted text I measured 15,140 tokens against 11,352 on the 4.5 models, 33% more. Because only the text part grows, the whole PDF went up 11% (38,354 vs 34,569), and the scanned PDF, which has no text, didn't move at all. If you're budgeting a migration off Haiku 4.5, the Haiku 5.5 vs Haiku 4.5 cost breakdown covers the rest.

Takeaway: count tokens on the model you'll actually run. Text-heavy PDFs grew 11% to 23% on 4.7+ models in my files; scans stayed flat.

Input cost for 1,000 copies of the 15-page paper at standard list prices, no caching, no batch discount, output tokens not included:

Haiku 5.5 is absurdly cheap here, but watch its pricing cliff: prompts over 100,000 tokens jump to $0.50 per million, five times the base rate, and the whole request pays it. At ~2,560 tokens per page, a paper-style PDF crosses 100K at about 39 pages. A dense form crosses it at about 26. A pure scan gets to about 64 pages. For long documents on Haiku 5.5, splitting the PDF into two requests is a real saving, not a micro-optimization.

Page limits matter too: 600 pages per request, but only 100 when the request's context window is under 1M tokens, and the 32 MB request cap can hit first. My 15-page paper was 2.2 MB; my 13-page scan at only 150 DPI was already 4.8 MB.

Sending the text was 2.5x cheaper on the paper and 1.7x cheaper on the W-9. That's not a reason to strip every PDF, though. The page image is what lets Claude read a chart, a checkbox, a table whose columns only make sense visually, or a signature line. Here's how I route it:

• Send text: contracts, transcripts, articles, policies, email exports. Anything where a plain-text copy loses nothing.
• Send the PDF: forms, invoices, statements, slide decks, anything with charts or tables. pdftotext dropped every checkbox on the W-9 and scattered the field labels away from their boxes; the PDF keeps them where they belong.
• Always send the PDF for scans: no text layer means nothing to extract. The good news is a scan only pays the image, ~1,555 tokens per page. The same 13-page report cost 20,215 tokens scanned vs 33,757 with its text layer. You trade a bit of OCR accuracy for 40% fewer tokens.
• Mixed documents: split them. Send the text pages as text and only the pages with tables or charts as a PDF. With a fixed 1,560-token image tax per page, this adds up fast.

Takeaway: the PDF route is worth paying for when layout carries meaning. When it doesn't, you're paying 1,560 tokens a page for pictures of paragraphs.

Yes, by about a fifth. With citations: {enabled: true}on the document block, the 13-page report went from 33,757 to 40,461 input tokens on Opus 5.5 and Haiku 5.5 (40,544 on Sonnet 5.5), and from 27,381 to 33,833 on the 4.5 models. That's +20% and +24%. The document gets split into citable chunks, and those chunks cost tokens.

Citations are worth it when a human checks the answer against the source: legal review, compliance, customer-facing "where does it say that?" answers. For a pipeline that pulls an invoice total into a spreadsheet, it's 20% for nothing. One related note from the docs: on the legacy Amazon Bedrock Converse API it's the reverse. Without citations, Converse falls back to text-only extraction, and visual PDF reading requires citations on.

For exact numbers, use the /v1/messages/count_tokensendpoint with the model you'll run. The docs list it as free, with its own rate limit. But in an n8n workflow I don't want an API round trip just to decide routing, so I estimate locally from the two numbers above. This uses poppler's pdfinfo and pdftotext, nothing else:

import subprocess, sys

PAGE_IMAGE_TOKENS = 1560   # measured: flat per page, any page size, any current model
CHARS_PER_TOKEN = 2.7      # Claude 4.7+ tokenizer on English prose; use 3.5 for Sonnet 4.6 and older

def pdf_pages(path: str) -> int:
    info = subprocess.run(["pdfinfo", path], capture_output=True, text=True, check=True).stdout
    return int(next(l.split()[-1] for l in info.splitlines() if l.startswith("Pages:")))

def estimate(path: str) -> dict:
    pages = pdf_pages(path)
    text = subprocess.run(["pdftotext", path, "-"], capture_output=True, text=True).stdout
    text_tokens = int(len(text) / CHARS_PER_TOKEN)
    return {
        "pages": pages,
        "as_pdf": pages * PAGE_IMAGE_TOKENS + text_tokens,
        "as_text": text_tokens,
        "scanned": len(text.split()) < 30 * pages,  # almost no text layer -> must send the PDF
    }

for path in sys.argv[1:]:
    print(path, estimate(path))

Against the four measured files:

$ python3 estimate_pdf_tokens.py attention.pdf fw9.pdf report.pdf report_scanned.pdf
attention.pdf        {'pages': 15, 'as_pdf': 38184, 'as_text': 14784, 'scanned': False}   # real: 38,354
fw9.pdf              {'pages': 6,  'as_pdf': 23370, 'as_text': 14010, 'scanned': False}   # real: 22,683
report.pdf           {'pages': 13, 'as_pdf': 37380, 'as_text': 17100, 'scanned': False}   # real: 33,757
report_scanned.pdf   {'pages': 13, 'as_pdf': 20284, 'as_text': 4,     'scanned': True}    # real: 20,215

Within 1% on the paper and the scan, 3% on the form, and 11% high on the report. That report is generated filler text, and odd vocabulary tokenizes differently than real prose. It mostly errs high, which is fine for a budget check. The scannedflag is the bit I actually use for routing: fewer than 30 extracted words per page means there's no usable text layer, so the PDF goes in as-is.

• Trim pages before sending.Cover pages, tables of contents, references and legal boilerplate each cost the full image tax. Dropping the paper's two full reference pages would save over 3,100 image tokens per call, before counting their text.
• Cache documents you ask about more than once. Put cache_control on the document block. On Opus 5.5 and Sonnet 5.5 a cache hit is 5% of the input price, so the second question about the paper costs about $0.004 on Sonnet 5.5 instead of $0.077. My prompt caching guide has the break-even math.
• Upload once with the Files API. Referencing a file_idkeeps the request small and avoids re-sending base64 on every call. It doesn't make the tokens cheaper. The Files API notes cover the details.
• Batch bulk extraction. If nobody is waiting, the Message Batches API halves both input and output. See my Batch API cost breakdown.
• Pick the smallest model that reads the document correctly. All three 5.5 models produced the same token count, so the price per million is the only lever. Run a few of your real documents through the cheaper model and check the extracted fields before you downgrade.

A cached document block with the Files API looks like this:

{
  "type": "document",
  "source": { "type": "file", "file_id": "file_011..." },
  "cache_control": { "type": "ephemeral" }
}

Takeaway: the biggest wins are routing text as text, trimming pages, and caching repeat questions. Model choice comes after that.