Why ChatGPT and Claude didn't really read your file

You attached the document and asked about it. The answer came back fluent, specific and confident — and about something the document does not say. Or about only its first few pages. Or about a table whose numbers have quietly landed in the wrong rows.

The reflex is to blame comprehension and rewrite the prompt. The fault is almost always earlier: the content never reached the model in the form you assumed.

Both vendors publish what they accept — formats, size caps, page ceilings. Neither publishes what happens between the upload and the model, and that gap is where every failure below lives. Each has a fingerprint, and reading it is what stops you arguing with an answer that was never about your file.

What "reading" actually means here

No model opens a file. Something upstream converts it to tokens first, and the shape of that conversion decides what is possible to get right.

Anthropic documents the PDF path plainly: "The text from each page is extracted and provided alongside each page's image." Two representations of the same page, both handed over — which is why Claude can answer about a chart at all. OpenAI's file inputs work the same way for PDFs and diverge sharply for everything else, where the extraction is text and only text.

So where a text layer exists you get text; where it does not you get pixels, and only if the pipeline rendered any. Which one you got is displayed nowhere, and a confident answer looks identical either way.

The page has no text layer, so there was nothing to extract

A scanned contract, a photographed page and a deck flattened to images all look like PDFs and behave like blank paper to a text extractor.

The fingerprint: the answer is fluent but non-committal, reuses your own words back at you, and is right about anything printed large and wrong about anything printed small. On the vision path the model reads letters off an image rather than receiving characters, so it behaves the way you would reading a bad photocopy — headings survive, body text degrades, footnotes and stamped figures become guesses.

The test takes ten seconds. Try to select a sentence in the file with your cursor. If nothing highlights, nothing was extracted. OCR it, and read the OCR output rather than trusting that it ran.

It is not a PDF, and the charts are simply not there

Nobody suspects this one, because the file opened perfectly on their own screen.

OpenAI states the constraint directly: "For non-PDF files, the API doesn't extract embedded images or charts into the model context." Anthropic says the same of non-PDF uploads to Claude. So a Word document containing three charts arrives as prose with three silent holes in it, and a deck whose content lives inside pictures arrives as titles and speaker notes.

The fingerprint: the model handles the surrounding paragraphs accurately, then produces a plausible invented description of the visual. It is not hallucinating out of nowhere — it is filling a gap nothing told it existed. The fix is the one OpenAI's own page recommends: export to PDF and attach that, so the pages are rendered as images.

A table is two-dimensional and the model receives one dimension

Extraction produces a linear stream of tokens; a page is a plane. Everything a layout encodes by position — which column a number sits under, that the page has two columns and not one — has to survive the flattening, and often does not.

Three fingerprints, all common:

• Values under the wrong header. Every number in the answer exists in your table; the labels have shifted by a column.
• Sentences that read as gibberish. A two-column PDF extracted left-to-right interleaves the columns line by line, and the model summarises a text no human wrote.
• Merged cells doubled or dropped. A cell spanning three columns becomes one value where three were expected.

Make the model show its working: ask it to reproduce the table as markdown before asking anything about the contents. If the reproduction is wrong, every conclusion drawn from it is wrong for the same reason, and no rewording fixes that.

The ceiling truncated it rather than refusing it

Every vendor publishes limits on pages, size and file count. What those pages do not stress is that exceeding one often degrades the result rather than producing an error.

Anthropic's upload documentation is unusually candid: "For PDFs from 101 to 1000 pages, Claude processes text only and doesn't analyze visual elements." (Checked 23 August 2026 — treat any such threshold as a figure that moves.) Nothing fails, nothing warns you, and a long report simply loses every chart in it.

The fingerprint is a good answer with a boundary: everything it says is correct, and everything it says comes from one region of the file — the early pages, or the prose but never the figures. Spot that boundary and stop debugging the prompt; measure the document instead. Whether the size also cost you is a separate question.

It searched the document instead of reading it

This is the biggest single source of "the AI summarised the wrong part of my document", and a different mechanism from everything above.

When a document lives in a project or a knowledge base rather than in the message you just sent, it may not be loaded at all. Anthropic documents the switch: "When RAG is enabled for your project, Claude uses a project knowledge search tool to retrieve relevant information from your uploaded documents." OpenAI's retrieval stack is built the same way — "When you add a file to a vector store it will be automatically chunked, embedded, and indexed" — so what reaches the model is whichever fragments a search returned for your particular wording.

The fingerprint is unmistakable once you look for it: the answer is excellent about one section and blank about another, and re-asking in different words changes which section it knows. That is not forgetting. That is a different search returning different chunks.

Two consequences worth keeping. A question phrased in your vocabulary rather than the document's retrieves badly, and a fact stated once in passing is easy to miss entirely. And "summarise this whole document" is close to unanswerable this way, because no single search returns all of it — which is why the summary covered a third of the file and read as though it covered everything.

The attachment is twenty turns back and has been trimmed away

An attachment is not a fixture of a conversation. It is a block of tokens at some point in the history, and long conversations do not keep their history intact.

Anthropic describes the mechanism directly: "When your conversation approaches the context window limit, Claude summarizes earlier messages to continue the conversation seamlessly." A summary of your document is not your document. Details survive at whatever resolution the summariser thought they deserved, which is why the model is fine on the shape of the file and wrong on any number in it.

This fingerprint is temporal, and that makes it easy to confirm: a question answered correctly an hour ago is answered vaguely now, and nothing about the file changed. Re-attach, or start a fresh conversation with the file and the question together — which is also the cheapest habit there is, for reasons that page covers. The wider effects of a long thread are their own article.

Attaching to a message and adding to knowledge are different acts

The same file, uploaded through two different buttons, gets two different lifetimes and two different retrieval behaviours. Attached to one message it is present in that conversation in full, until it is trimmed. Added to project knowledge it persists across every conversation in the project, and is very likely searched rather than loaded.

So the right answer to "why does it not remember my style guide" and the right answer to "why did it miss clause 14" are opposites — the first a persistence problem, the second a retrieval problem. Moving the file to fix one can create the other.

Worth stating plainly: uploading a document does not by itself tell the model to follow it. That distinction — material versus instruction — is its own article. Here it matters as a symptom: an ignored style guide is usually placed correctly and framed wrongly.

The file must be fetched, and fetching is a decision

A link is not an attachment. A file referenced by URL, a document in a connected drive, a page behind a connector — none of these are in the request. Something has to fetch them, and that something is a tool the model chooses to call, or does not.

OpenAI's Projects documentation is explicit that connected apps behave this way rather than pre-loading: "You can still use the app to search and access relevant files, but content will not be synced in advance for retrieval." The fingerprint is a model answering from the URL itself — the slug, the filename, the domain — with no sign of the contents.

Two checks. Is there evidence a fetch happened: a citation, a tool indicator, a quotation you can find in the file? And is the resource reachable by something that is not your logged-in browser — a login wall, an expired share link and a private repository all produce the same confident nothing. If the tool exists and is not called, that has its own causes.

It answered from the famous version, not from your copy

The hardest one to see, because the answer is not wrong in general — it is wrong about you.

Attach a standard lease, a well-known licence, a published paper or a circulated policy template, and the model already knows a version of that document. If your copy carries redlines, a struck clause or a changed number, an answer from prior knowledge will be smoothly, confidently generic. Anthropic's troubleshooting note describes the register exactly: "Claude can display quotes that may look authoritative or sound convincing, but are not grounded in fact."

The fingerprint is a mismatch between confidence and specificity: correct on everything the public version says, wrong or silent on everything unique to yours. Ask for the exact wording of the clause you changed. A copy that was really read quotes your text; prior knowledge produces the canonical text, or a paraphrase that avoids committing.

Three probes that tell you what it saw

Before diagnosing a cause, establish whether the content is there at all. Each takes one message.

1. Ask for a verbatim quotation from a place you choose. Name a section and ask for its first sentence, exactly. Extraction failures, truncation and retrieval misses each fail this differently — nothing, the wrong section, or a paraphrase.
2. Ask about something only your copy contains. A signature block, a handwritten note, a changed number. This separates "read the file" from "knows this kind of file".
3. Ask it to describe the layout. How many columns, where the table starts, what the chart on that page shows. A vision path can answer; a text-only path will guess.

If all three pass and the answer is still poor, only then is rewriting the prompt the right move.

The order to check these in

Cheapest and most likely first.

1. Can you select text in the file? No means no text layer. OCR it.
2. Is it a PDF? If not, assume every embedded image and chart is missing.
3. How far into the document does the answer go? A hard boundary is a ceiling, not an opinion.
4. Is the file in the message, or in project knowledge? Knowledge means searched — name the document and the section.
5. How far back is the attachment? If it is old, re-attach or start fresh.
6. Is it a link rather than a file? Then confirm a fetch actually happened.
7. Does it reproduce your table correctly? If not, the flattening is the bug.
8. Is your copy of a well-known document non-standard? Ask for the wording you changed.

Most of these are answered by looking at the file rather than at the model, which is the point. The interface gives you one signal — the answer — for a pipeline with eight places to fail. The useful skill is not better prompting. It is knowing which of the eight produced the answer in front of you.