How many pages can GPT actually read? The direct answer, plus a table

By LW Forge — maintainer of LLM Scout · Updated August 3, 2026

The short answer: for a dense, text-heavy page, a 200,000-token context window holds around 400 pages, and a million-token window holds around 2,000. That covers the overwhelming majority of business documents — contracts, reports, theses — in a single request on current mid-to-large models. The rest of this article covers why that number moves, and what to do when your document doesn't fit.

The table, by context window size

Using an average of roughly 500 tokens per dense text page — the same figure behind the how many pages fit in GPT calculator — here's what the common context window tiers translate to:

That's the starting point — your actual document will land somewhere around these numbers, not exactly on them, for reasons that matter more than the model you pick.

Why "it depends" is the honest answer

Page density swings the real number substantially in both directions. Slide decks, forms, and pages with lots of whitespace or large images can run as low as 100-200 tokens per page — you'll fit noticeably more of those than the table suggests. Dense legal contracts, financial statement tables, and source code listings can push past 700 tokens per page, sometimes close to double the average — you'll fit noticeably fewer. The 500-token figure is a reasonable planning average for prose-heavy business documents, not a hard constant.

The only way to know for certain is to measure: extract the text from a representative page or two of your actual document and run it through the token calculator.

This matters most right around the ceiling. If your document is comfortably under a model's limit — 50 pages against a 400-page budget — density swings by a few hundred tokens per page won't change your decision. If it's close — 380 pages against that same 400-page budget — the same swing is the difference between one request and a split document, so that's exactly when it's worth measuring instead of estimating.

Chat upload vs. API — different limits entirely

The context window is a model-level ceiling, but the chat products (ChatGPT, Claude.ai) often impose their own, separate limits on file size or page count per upload, independent of what the underlying model could technically hold — those product limits change more often than model specs and are worth checking directly on the provider's site if you're working through the chat interface rather than the API. Through the API, there's no upload limit beyond the context window itself — you're constrained only by tokens, not by file size or page count as such.

Two things that quietly break this math

Scanned PDFs aren't text. A scanned document is a sequence of images; none of the page-to-token math above applies until it's been through OCR to extract actual text. Skip that step and you're either sending images to a vision-capable model (a completely different pricing structure, billed by image tokens rather than text tokens) or getting no usable text at all.

The model re-reads the whole document every time. Because models are stateless, a follow-up question about the same document re-sends and re-bills the entire thing, not just the new question — asking ten questions about a 400-page document costs roughly ten times the input of asking one. If you'll query the same document repeatedly, prompt caching or an indexed retrieval setup will beat re-sending the full text on every turn.

Multiple documents compound the same way. A folder of ten 200-page contracts isn't one 2,000-page problem unless you actually need cross-document reasoning — treating it as ten separate 200-page requests is usually both cheaper and more accurate, since each request only has to attend to the one contract that's actually relevant.

When the document doesn't fit

In roughly descending order of how much you'll need to change:

1. Switch to a larger-window model, if quality and price allow — no pipeline changes required, just a different endpoint.
2. Split along the document's own structure — chapters, sections, or logical breaks, never an arbitrary token cutoff that severs a sentence from its context.
3. Use retrieval — index the document once and send only the passages relevant to each question, which typically cuts cost as much as it solves the fit problem.
4. Summarize first and work from the summary, accepting some loss of fine detail — price that route with the PDF summary calculator.

Check your specific document

Averages get you a planning estimate; your actual document gets you a real answer. Run a real sample through the token calculator, see the full page-count table by model in the how many pages fit in GPT calculator, and if you're deciding between a bigger window and a retrieval pipeline, context window in practice covers that tradeoff in more depth.