I once had an automation summarize a forty-page pricing PDF, and it confidently described a plan tier that did not exist. The model was not hallucinating out of nowhere: I had scraped the PDF to text first, the scrape had mangled a pricing table, and Claude faithfully summarized the garbage I fed it. I had built a scrape-and-pray pipeline and blamed the model for the pray part failing.
The fix was to stop scraping and hand Claude the actual file. On the API you can give it the real PDF, the real screenshot, the real deck, and let its vision read what is genuinely there, tables and layout included. This guide covers feeding Claude real documents and images, reusing them across calls, and grounding its answers in citations you can check.
Claude reads your documents directly
You do not have to reduce a document to plain text before Claude can use it. The API accepts real files, PDFs, spreadsheets, documents, and real images, and works from them directly. That removes an entire fragile step, the extraction, that is responsible for a surprising share of bad outputs, because a mangled extraction produces a confident summary of nonsense.
The principle underneath is the one that runs through all of prompting: hand Claude the source, not your lossy version of it. A scrape is a summary you did badly and silently; the original file is the ground truth. Give it the ground truth and a whole class of errors disappears.
Vision reads what text extraction misses
Vision means Claude actually reads images, not just notices they exist. That includes the things text extraction destroys: a pricing table where columns and rows carry meaning, a chart where the trend is the point, a dashboard screenshot, a photo of a whiteboard. Extraction flattens all of that into a jumble; vision reads it as the structured thing it is.
For GTM this is the difference between usable and not on a lot of real inputs. A competitor's pricing page, a screenshot of a dashboard a prospect shared, a slide from their deck, these are visual documents, and asking about them only works if the model sees them as images rather than a scrambled text dump.
A practical note on quality: vision reads a clear image far better than a blurry one, so a clean export or a full-resolution screenshot beats a compressed thumbnail. When an answer about an image seems off, the first thing to check is whether the image itself was legible, the same way you would not blame a colleague for misreading a bad fax.
The Files API: upload once, reference everywhere
When the same document shows up in many calls, uploading it every time is wasteful. The Files API lets you upload a document once and get back a reference you can reuse across calls, so a product doc or a long report lives on Anthropic's side and you point to it rather than re-sending it each time.
This pairs naturally with prompt caching for the same reason: both are about not re-transmitting and re-paying for content that does not change. Upload the stable reference material once, reference it, and keep your per-call payload to just the new question.
TipFor a document many calls will use, upload it once with the Files API and reference it, rather than attaching it to every request. Less to send, less to pay, one source to update.
PDFs: text and layout together
PDFs are the workhorse document of GTM, contracts, one-pagers, reports, decks exported to PDF, and the API handles them with both their text and their visual layout. That combination matters, because a PDF's meaning often lives in its structure: which number is in which column, what the table says, how the sections relate. Reading text and layout together is what keeps a pricing table a table.
This is exactly what my scrape-and-pray pipeline got wrong. The scrape kept the words and lost the structure, so the pricing table became a stream of numbers with no columns, and the summary invented a tier. Handing over the PDF itself keeps the structure intact, and the answer stays true to the document.
Citations: grounding answers in the source
Citations let Claude tie its claims to the specific passages of the source it used, so instead of a fluent answer you have to take on faith, you get an answer you can check against the exact lines it came from. For anything that will end up in front of a prospect or a decision, that verifiability is the whole point.
This changes how much you can trust an automated document workflow. A summary with citations is one where you can spot-check the load-bearing claims against the source in seconds; a summary without them is one where a confident hallucination looks exactly like a fact. When accuracy matters, turn citations on and check the claims that matter.
Files with structured output and tools
Files get more powerful combined with the other API features. Pair a document with structured output and you get clean data extracted straight from a PDF: hand over an invoice or a signed order form and get back the fields your system needs, shaped and validated. Pair it with tool use and an agent can pull a document, read it, and act on what it found, all in one loop.
This is how document-heavy GTM automation actually gets built: not vision alone, but vision feeding a schema, or a file feeding an agent. The competitor pricing PDF becomes a structured comparison table; the prospect's shared deck becomes tagged priorities in your CRM. The file is the input, and the other features turn what Claude reads into something your systems can use directly.
What it reaches, and what it does not
Handing over a file gives Claude the content of that file, not the internet around it. It reads what you provide, so if a report references data that lives elsewhere, Claude only has the reference, not the data, unless you provide that too. This is obvious stated plainly and easy to forget when an answer is fluent enough to sound omniscient.
There are also practical limits on size and pages, so a giant document is not automatically read cover to cover in the way you assume. Know roughly what you handed over and what a single call can realistically take in, so you are not trusting an answer that was based on the first few pages of a document you thought it read whole.
Where it goes wrong
The main trap is assuming full coverage of a large document. A fluent summary of a hundred-page report can be a fluent summary of the part the model actually attended to, so for big documents, either confirm the whole thing was in scope or break it into pieces you know were read. Do not let fluency stand in for coverage.
The others are cost and the old scrape reflex. Documents and images are more tokens than a line of text, so a workflow over big files costs more, and it is worth knowing that before you run it at scale. And the reflex to pre-process, to scrape the PDF to be safe, is usually the thing to drop: the file itself is almost always the better input.
- Assuming a huge document was read cover to cover; confirm coverage or split it.
- Forgetting files and images cost more tokens than plain text, which adds up at scale.
- Scraping to text first out of habit, reintroducing the errors the file would have avoided.
- Trusting a fluent answer with no citations when the claims will be acted on.
The GTM version
This is the feature set behind document-heavy GTM automation done right. Feed a competitor's pricing PDF and ask where you win and lose, with citations. Hand over a prospect's shared deck and pull out their stated priorities. Drop in a call recording's transcript alongside the account's one-pager and draft a grounded follow-up. In each case the move is the same: give Claude the real source, not a scrape, and let it read what is actually there.
The forty-page pricing PDF that invented a tier now gets summarized from the actual file, tables intact, claims cited, and the phantom plan never appears. Hand it the ground truth. What document is your team currently scraping, pasting, or eyeballing that you could just give Claude whole?
How to set it up
Send the real file, not a scrape
Attach the actual PDF or image to the request instead of extracting text first. Claude reads the content and layout directly:
Upload once if many calls will use it
For a document reused across calls, upload it with the Files API and reference the returned id, rather than re-attaching it every time. Pair it with prompt caching to keep the shared context cheap.
TipOne uploaded reference beats re-sending the same PDF on every call: less payload, lower cost, and a single place to update the source.
Turn on citations for anything you'll act on
Ask for citations so Claude ties its claims to the passages it used. Then spot-check the load-bearing claims against the source before the output reaches a prospect or a decision.
Confirm coverage on big documents
For a large file, either confirm the whole thing was in scope or split it into parts you know were read. A fluent summary of a hundred pages can quietly be a summary of the first few.
Frequently asked questions
Can Claude read PDFs and images directly?
Yes. The API accepts real files and images, including PDFs, spreadsheets, screenshots, and charts, and reads them directly. You do not need to extract text first, and you generally should not.
What does vision add over text extraction?
Vision reads what is actually in an image, tables, charts, screenshots, layout, that text extraction flattens or mangles. For visual documents like a pricing page, it is the difference between a correct answer and a scrambled one.
What is the Files API for?
Uploading a document once and referencing it across many calls, instead of re-sending it every time. It pairs well with prompt caching to keep reused reference material cheap.
Why give Claude the PDF instead of scraped text?
Because a scrape keeps the words and loses the structure, so tables and layout get mangled and summaries can invent details. The PDF preserves text and layout together, keeping the answer true to the document.
What are citations?
They tie Claude's claims to the specific source passages it used, so you can verify an answer against the exact lines instead of trusting it. Essential for anything that will be acted on.
Does Claude read every page of a big document?
Not necessarily. There are size and page limits, and a fluent summary can reflect only the part the model attended to. For large documents, confirm coverage or split them into pieces you know were read.
Do files and images cost more?
Yes, they are more tokens than plain text, so document-heavy workflows cost more at scale. Know that before running one over many large files, and use the Files API and caching to avoid re-sending.
What GTM tasks does this open up?
Document-heavy work done right: analyzing a competitor's pricing PDF with citations, pulling priorities from a prospect's deck, drafting a grounded follow-up from a transcript plus a one-pager. Give it the real source each time.
Sources & further reading
Claude ships fast. This page was last reviewed Aug 23, 2026; verify time-sensitive details against the official docs above before relying on them.