On most platforms, sending Claude a PDF works one way: the system converts each page into an image and extracts the page's text, and Claude analyzes both together. That is why Claude can read a table, describe a chart, and quote a paragraph from the same page. On Amazon Bedrock's legacy Converse API, however, there are two distinct PDF processing paths, and which one you get is controlled by a setting that sounds unrelated: citations.
The two modes, side by side
Anthropic's PDF support documentation names them explicitly:
| Converse Document Chat | Claude PDF Chat | |
|---|---|---|
| When it applies | Citations off (default) | Citations enabled |
| What Claude sees | Extracted text only | Each page as text + image |
| Visual understanding | None — charts, diagrams, and scanned layouts are invisible | Full visual analysis |
| Rough cost example | ~1,000 tokens for a 3-page PDF | ~7,000 tokens for the same 3-page PDF |
The token difference is the whole trade-off in miniature. Document Chat strips the PDF down to its text layer, which is cheap and perfectly adequate for contracts, policies, and other text-dominant documents. Claude PDF Chat processes every page as an image alongside its text — roughly seven times the tokens in the documented example — but it is the only Converse path where Claude can actually see figures, charts, stamps, and layout.
The citations coupling
Here is the constraint that trips teams up: on Bedrock's Converse API there is no way to get visual PDF analysis without enabling citations. The citations flag is what flips you from Document Chat into Claude PDF Chat. If your users report that Claude "isn't seeing" the charts in their PDFs on Converse, the documented fix is to enable the citations flag — even if you never intended to display citations.
When InvokeModel is the better door
Bedrock's other legacy entry point, the InvokeModel API, gives you the raw Anthropic Messages request shape and therefore direct control without the forced coupling: you decide independently whether you want citations and how documents are handled, the way you would on the first-party API. If you need visual PDF analysis but citations get in the way of your response processing, InvokeModel is the documented escape hatch. For the broader differences between the two, see Converse vs InvokeModel.
It is worth placing all of this on the map of Bedrock's two surfaces. Converse and InvokeModel belong to the legacy surface with anthropic.-prefixed, ARN-versioned model IDs. The current "Claude in Amazon Bedrock" surface is the Anthropic Messages API itself (the AnthropicBedrockMantle client in Python), where PDF handling follows Anthropic's standard model. On Bedrock, PDFs must be supplied as base64-encoded document blocks — URL references and Files API uploads are not currently available there.
Shared limits, whatever the mode
The platform-agnostic PDF limits still apply on Bedrock: a maximum request size of 32 MB (varies by platform) and up to 600 pages per request — 100 pages when the request's context window is under 1M tokens — with standard, unencrypted PDFs only. Text typically costs 1,500–3,000 tokens per page depending on density, and because each page is also processed as an image in full PDF mode, image costs follow the standard image-size calculations. Dense PDFs can fill the context window before hitting the page limit; the docs recommend splitting large documents and downsampling embedded images. For estimating spend before you commit, the token counting API works with document blocks, and PDF token costs walks through the arithmetic.
One format note that saves support tickets: .docx and .xlsx files are not supported in document blocks anywhere — convert them to text or PDF first.
Where to go next
For the PDF pipeline as a whole, read PDF support across platforms and scanned-PDF limitations; for pairing PDFs with retrieval, see the multimodal document pipeline pattern.