How to Prompt with Uploaded Files and PDFs

TL;DR: ChatGPT, Claude and Gemini each read an uploaded file differently: extracted text only, page images via vision, or executed code for spreadsheets. Each vendor documents its own size and page ceilings, and one of them (Gemini's Files API) deletes uploads after 48 hours by default. Ask for a direct quote as proof the model reached the passage you meant, and check a PDF's text layer before you trust anything it "read."

What actually happens when you upload a file to ChatGPT?

For anything ChatGPT treats as a document, a PDF, a Word file, a plain-text file, it extracts the digital text and discards the images inside it, unless you are on ChatGPT Enterprise, which gets a separate visual mode. For spreadsheets and other structured data, it does something else entirely: it writes and runs Python in a notebook environment and works with the real file, not a text description of it.

OpenAI's own File Uploads FAQ (accessed September 3, 2026) draws the line plainly: "All other plans and document files only support text-based retrieval. This means that ChatGPT will extract digital text from the file and discard any images." Enterprise is the documented exception: "ChatGPT Enterprise supports Visual Retrieval for PDF files."

That one sentence explains most of the confusing behavior people report. Ask ChatGPT, on a non-Enterprise plan, what a chart in your PDF shows, and it never received the chart. It is inferring from whatever text sat near it, which is why the answer can be fluent and wrong at the same time.

Spreadsheets get a genuinely different pipeline. OpenAI's data-analysis documentation says it directly: "For some data-analysis tasks, ChatGPT writes and runs Python code in a stateful Jupyter notebook environment." A well-formed CSV gets pandas-grade precision, real row counts and real sums, instead of a language model guessing at digits it saw somewhere in a wall of extracted text.

Retrieval or full-context stuffing: which one is your tool doing?

The distinction matters because the two approaches fail in opposite ways. A tool that stuffs your whole file into its context window can reason about the document as a whole, but it hits a hard page or size ceiling and gets expensive fast. A tool that does real retrieval only sees the passages it judged relevant to your specific question, so it can quietly miss something real that simply wasn't in the top match.

Claude's and Gemini's PDF handling is the context-stuffing kind. Anthropic documents exactly what happens to a PDF you send, in two steps: "The system converts each page of the document into an image." Then, "The text from each page is extracted and provided alongside each page's image." Everything you send counts against the model's context window and against a hard page ceiling, covered below.

OpenAI runs a genuinely different, and genuinely retrieval-based, tool for developers building on its API. Its file search documentation is explicit about the mechanism: it "enables models to retrieve information in a knowledge base of previously uploaded files through semantic and keyword search." In practice that means chunking your files, embedding the chunks, and returning only the pieces that matched your query. That is real retrieval, and it is not what happens when you drag a PDF into the ChatGPT web app for a normal conversation.

The practical fix holds regardless of which mechanism you're on. Do not ask "summarize this." Ask "quote the exact sentence that states X, then summarize the paragraph around it." If the model cannot produce the quote, it did not reach the passage, whether because retrieval missed it or because the file blew past a size limit before that page was ever read.

How big a file can you actually upload?

Smaller than you'd guess on Claude's page ceiling, more generous on Gemini's, and every vendor treats retention on its own terms.

Two of those rows are worth flagging before you build a workflow around them. Google's Gemini Files API states, without qualification, "Files are automatically deleted after 48 hours." That is a far shorter window than either OpenAI or Anthropic documents, and it is easy to assume your upload will still be there tomorrow when the vendor's own default says otherwise.

Anthropic's Files API defaults the other way. Its own documentation states: "Files persist until you delete them with the DELETE /v1/files/{file_id} endpoint or they reach their expires_at". That field is null by default, meaning no automatic deletion, unless you set one explicitly at upload time.

OpenAI ties file lifespan to chat lifespan. Its own FAQ states: "Files uploaded to ChatGPT are saved in your account up to the retention period of the corresponding chat." Deleting that chat or your account removes the file within 30 days, unless it's already de-identified or held for legal or security reasons. Three vendors, three defaults. Check the one you are actually using rather than assuming any of them behaves like the other two.

Why does ChatGPT treat my spreadsheet differently than my PDF?

Because a spreadsheet is data you want computed on, and a PDF is prose you want read, and OpenAI's own documentation routes the two through different systems entirely. A CSV or Excel file goes to a live Python environment; a PDF or Word document goes through text extraction.

That split explains a common complaint. Someone uploads a PDF export of a spreadsheet, asks for a sum, and gets a plausible-but-wrong number. The PDF path never ran any arithmetic; it extracted text and pattern-matched the request against it. If exact values matter, upload the source spreadsheet, not a PDF rendering of it, so the request actually reaches the code-execution path rather than the text-extraction one.

The same logic applies in the other direction. Asking ChatGPT to "analyze the layout" of a spreadsheet, or the visual formatting of a table, gets a worse answer than asking it to analyze a PDF or an image of that same table, because the code-execution path reasons about values and structure, not appearance.

Why do scanned PDFs fail, and how can you check first?

A scanned PDF is a picture of text with no digital text layer underneath it, and outside a vision-based reading path, a text-extraction tool finds nothing there to extract. OpenAI's own documentation names this exact failure directly: "ChatGPT may not reliably extract exact values from image-based tables, scanned files, or files with complex visual layouts. When exact values matter, upload a spreadsheet or text-based file instead."

The check costs ten seconds and needs no special tool. Open the PDF in any viewer, try to select a line of text with your cursor, and copy it. Real, correctly spelled words mean there is a text layer, and the extraction path should work. Nothing selectable, or a highlighted block that pastes as gibberish, means you are holding a scan, and for a tool that only does text-based retrieval, that page might as well be blank.

Claude and Gemini are less brittle here specifically because they process every PDF page as an image regardless of whether a text layer exists. Anthropic's own best-practice guidance includes two lines aimed at exactly this: "Rotate pages to proper upright orientation" and "Use logical page numbers (from PDF viewer) in prompts". A crooked, low-resolution, or oddly numbered scan can still be misread by vision, just differently from a text-extraction miss. Neither failure mode announces itself. Both can look like a confident, on-topic answer.

A prompt template for any uploaded file

Use this shape whichever model you're on. It forces the specificity that fixes most bad upload results before you send anything.

I've attached [file type: a 40-page PDF report / a CSV of Q3 orders / a scanned contract].

Task: [the one output you need — not "summarize," name the actual deliverable].
Scope: [the section, date range, or column that matters — not "the whole file"].
Proof: Before you answer, quote the exact sentence or row that supports it.
If you can't find it, say so instead of guessing.
Format: [table / bullet list / one paragraph — say which].

The "Proof" line does the most work in that template. It converts a fluent guess into a checkable claim, and it is the fastest way to notice you've hit a scanned-PDF problem, a page-limit cutoff, or a retrieval miss, because the model will either produce the quote or it won't.

A troubleshooting checklist before you hit send

• Run the copy-paste test on anything scan-adjacent: a contract, a mailed form, a printed report re-photographed on a phone.
• Check page count against the vendor's real ceiling: 100 pages on Claude if your request's context window is under 1M tokens, not the 600-page headline figure.
• Upload structured data (CSV, not a screenshot of a table) whenever exact values matter; no vendor's vision path guarantees precise numbers.
• Add the "Proof" line to every prompt on a document longer than a few pages, not only the ones you're suspicious of.
• Know your vendor's retention default before you treat an upload as anywhere you'd store something for more than a couple of days.

For screenshots, photos and diagrams rather than documents, the companion guide on prompting with images covers the vision-specific failures, cropping, chart misreads, resolution limits, that this page doesn't repeat. Once a document-analysis prompt is reliably working, saving it as a reusable template means you aren't rebuilding the "Proof" structure from a blank page every time. If the model keeps second-guessing a clear instruction on a long document, that's less a file-handling issue than a steering one, and advanced ChatGPT prompting covers how to give a reasoning model less hand-holding rather than more. Pairing either with Canvas's inline editing workflow is the fastest way to turn a first extraction into a polished deliverable without restarting the conversation.