Claude API for PDF Document Summarization

Can you summarize PDFs with the Claude API?

Yes. The Claude API accepts PDF files directly as document content blocks in a message, which means you don't need a separate OCR or text-extraction step for most PDFs — Claude reads the document, including embedded text, tables, and layout, and generates a summary from it in a single request. This makes it a practical choice for summarizing contracts, research papers, financial reports, or any multi-page document where you want a condensed, structured output.

The main thing to get right isn't whether Claude can read a PDF — it's how you structure the request, manage document size, and shape the prompt so the summary is actually useful (consistent length, correct focus, no hallucinated numbers). This article covers the practical setup: sending PDFs to the API, handling large documents, prompt patterns for different summary types, and streaming the output for better UX.

Sending a PDF to Claude for summarization

The Claude API supports PDF input as a base64-encoded document block alongside your text prompt. A minimal request looks like this:

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "messages": [{
      "role": "user",
      "content": [
        {
          "type": "document",
          "source": {
            "type": "base64",
            "media_type": "application/pdf",
            "data": "'"$(base64 -i report.pdf)"'"
          }
        },
        {
          "type": "text",
          "text": "Summarize this document in 5 bullet points, focusing on key figures and conclusions."
        }
      ]
    }]
  }'

Claude processes the PDF's text and visual layout together, so tables and multi-column reports generally summarize better than if you'd stripped the text out yourself and lost the structure.

PDF size and page limits

There are practical limits to how much you can send in one request — both in terms of file size and page count, and in terms of token budget. Very large PDFs (hundreds of pages) should be split before sending, either by logical sections (chapters, clauses) or by a fixed page range. A simple strategy:

1. Split the PDF into chunks of 20–30 pages.
2. Summarize each chunk independently with a consistent prompt.
3. Feed the chunk summaries back into Claude as plain text and ask for a final synthesis.

This two-pass approach (summarize-then-synthesize) is more reliable than trying to force a huge document through one call, and it keeps each individual summary focused rather than diluted.

Prompt patterns that produce useful summaries

A generic "summarize this" prompt produces generic output. For document summarization that's actually usable downstream, be specific about structure and intent:

Executive summary for decision-makers:

Summarize this document for a non-technical executive. Lead with the
single most important takeaway in one sentence. Follow with 3-5 bullet
points covering decisions needed, risks, and financial impact. Omit
background and methodology.

Structured extraction summary:

Produce a summary with these exact sections: Overview (2 sentences),
Key Findings (bulleted), Numbers to Verify (any figures mentioned),
Open Questions. Do not add sections beyond these.

Comparison across multiple documents:

I will give you two contracts. Summarize the differences between them
in a table with columns: Clause, Document A, Document B, Material
Difference (yes/no).

A few rules of thumb that consistently improve output quality:

• Ask for a fixed structure. Claude follows explicit formatting instructions more reliably than open-ended ones, and this also makes output easier to parse programmatically.
• Tell it what to exclude. "Omit methodology" or "don't include boilerplate legal language" prevents the summary from padding itself out.
• Request citations to page numbers or section headers if your use case needs traceability back to the source document — Claude can reference where in the document a claim came from.
• Set max_tokens deliberately. A 3-bullet summary doesn't need a 4096-token budget; capping it forces conciseness and reduces latency and cost.

Streaming long summaries

For longer documents where the summary itself runs to several paragraphs, streaming the response improves perceived latency — the user sees text appear instead of waiting for the full generation. This matters more than it sounds: PDF summarization requests often take several seconds just to process the document before generation even starts, so a streamed response makes the wait feel shorter.

Running this as a product feature, not just a script

If you're building PDF summarization into a product — a document review tool, a research assistant, a contract analyzer — calling the Claude API directly works for prototyping, but you'll run into the same operational questions every team does: how do you issue separate keys per customer or environment, how do you track token usage per feature, how do you roll a key without redeploying, and how do you keep billing logic out of your core app code.

This is the gap SubToAPI fills. It sits between your application and your Claude subscription, exposing a standard HTTPS API with scoped sub_live_... keys you can issue per project, per customer, or per environment — so your PDF summarization feature can have its own key, its own usage dashboard, and its own rate limits without touching your main Claude setup. Document and text requests work the same way they do against the Claude API directly: you send your messages payload (including document blocks) to SubToAPI's endpoint, and it streams back the response. If you're already prototyping with Claude for summarization, pointing production traffic at /docs/quickstart instead of managing raw provider credentials is a small change with a real operational payoff — see /docs/messages for the request format and /docs/streaming for streaming responses. Plans start at €9/month on the Solo tier with a free trial at /signup; full pricing is at /pricing.

Practical checklist

• Send PDFs as base64 document blocks, not extracted plain text, to preserve tables and layout.
• Split documents over ~30 pages into chunks and synthesize a final summary from chunk summaries.
• Use structured, section-based prompts instead of open-ended "summarize this."
• Cap max_tokens to match the summary length you actually need.
• Stream responses for any summary longer than a few sentences.
• If this becomes a product feature, separate it behind its own API key and usage tracking rather than sharing one credential across your whole app.

questions

Does Claude extract text from scanned (image-only) PDFs? Claude can process PDFs that are primarily images if the content is legible, since it reads documents visually as well as textually, but very low-quality scans may still produce incomplete summaries. For critical use cases, run a quality check on noisy scans before relying on the output.

What's the best way to summarize a 200-page PDF? Split it into chunks (by chapter or ~20–30 pages), summarize each chunk with a consistent prompt, then feed the chunk summaries back as text for a final synthesis pass. This avoids token budget and attention issues that come with forcing one huge document through a single call.

Can I control the summary format, like getting bullet points or a table? Yes — explicitly describe the structure you want in the prompt (exact section names, table columns, bullet count). Claude follows explicit formatting instructions far more consistently than vague requests like "summarize this briefly."