How Many Pages Fit in Each AI Model?
Based on an average of 400 tokens per typical text-dense PDF page.
~2,625 pages
1,050,000 token context window
~2,625 pages
1,050,000 token context window
~2,625 pages
1,050,000 token context window
~2,500 pages
1,000,000 token context window
~2,500 pages
1,000,000 token context window
~2,500 pages
1,000,000 token context window
~2,500 pages
1,000,000 token context window
~2,500 pages
1,000,000 token context window
~2,500 pages
1,000,000 token context window
~500 pages
200,000 token context window
~500 pages
200,000 token context window
~500 pages
200,000 token context window
Estimate only — actual tokens per page vary with font density, tables, and language. Scanned PDFs requiring OCR may use additional tokens.
How this page-count estimate works
This is a narrower, faster version of the context window calculator focused on one common question: how many PDF pages fit into a single request? We convert each model's context window into an approximate page count using an average tokens-per-page figure for dense text, sorted from largest to smallest context window. If your document exceeds a model's limit, you'll typically need to either switch to a larger-context model, split the document into chunks, or use a retrieval-based approach that only feeds the model the most relevant pages.
The short answer, in real page counts
Using the dense-text average of roughly 500 tokens per page, the common tiers translate to: a 128k window holds about 250 pages, 200k about 400 pages, and a million-token window around 2,000 pages. That covers the overwhelming majority of business documents — contracts, reports, theses — in a single request on current mid-tier models.
Real documents drift from the average, though. Slide decks and sparse layouts can drop to 100-200 tokens per page, while dense legal text, financial tables and source code listings can push well past 700. The table above is the right starting point; your document's actual density decides the final answer.
When the document doesn't fit
You have four options, in rough order of preference. Switch to a larger-window model, if quality and price allow — simplest, no pipeline changes. Split along the document's own structure — chapters or sections, never arbitrary cut points that sever sentences from their context. Use retrieval: index the document and send only passages relevant to each question, which typically also cuts cost dramatically. Or summarize first and work from the summary, accepting some loss of detail — you can price that route on the PDF summary calculator.
Page counts are a proxy — verify before you commit
Before building around any of these numbers, extract your document's text and check a sample in the token calculator. Two caveats catch people out: scanned PDFs contain images, not text, so they need OCR before any of this math applies; and sending pages as images to a vision model is billed under image-token rules, which follow a completely different price sheet from text.
How many pages each model can read at once
Converted into pages at roughly 500 tokens for a dense page, the August 2026 catalogue splits into two groups. The GPT-5.6 family — Sol, Terra and Luna — reads about 2,100 pages in a single call on its 1.05M-token window. Gemini 2.5 Pro and Flash, GLM-5.2, Kimi K3, Nemotron 3 Ultra and Llama 4 Maverick land near 2,000 pages on their 1M windows. The Claude family — Opus 4.8, Sonnet 5, Haiku 4.5 — reads about 400 pages on 200k tokens.
What that costs to read once, at list prices per million tokens, is the part people skip. Two thousand pages of input is 1M tokens: $5.00 on GPT-5.6 Sol, $0.20 on Luna, $1.25 on Gemini 2.5 Pro and $0.20 on Llama 4 Maverick. Four hundred pages on Claude Opus 4.8 is 200k tokens, about $1.00.
So the capacity question and the budget question have different answers: the models that read the most are not always the ones you want reading the most. Price your document in the PDF summary calculator, and see how many pages GPT really reads for the caveats.
Four documents, four verdicts
A 12-page research paper (~6,000 tokens) fits in every model on this list with room for a long discussion afterwards. Nothing to think about — pick on quality and price, not capacity.
A 250-page annual report (~125,000 tokens) fits in Claude's 200k window, but only just: after the document there is little room left for a multi-turn conversation about it. On a 1M-token model it is comfortable.
A 700-page textbook (~350,000 tokens) exceeds every Claude tier and fits only in the 1M-window group. Even there, expect degraded recall in the middle — chapter-level retrieval usually gives better answers than pasting the whole book.
A 5,000-page archive (~2.5M tokens) fits nowhere in a single call. This is a retrieval problem, not a context problem: index it, search it, and send the model the ten pages that matter. The context window calculator shows the exact limits, and the what fits guide covers the retrieval alternative.
Frequently asked questions
What counts as a 'typical' page for this estimate?
We assume a standard, text-dense page — think a contract or a research paper, not a page with lots of whitespace or large images. Sparse pages will fit more pages per context window than this estimate suggests.
My PDF has images and tables — does that change things?
Yes, usually upward. Tables and dense layouts tend to tokenize less efficiently than plain prose, and pages that need OCR can use noticeably more tokens per page than digitally native text.
Which model should I pick for a very long document?
Check the context window calculator above for the full ranking. As a rule of thumb, if your document is close to a model's page limit, leave headroom for your prompt instructions and the model's output.
Does the model re-read the whole document for every question?
Yes — models are stateless, so each request is billed for every token it contains, including the document, every time. If you'll ask many questions about one document, prompt caching or a retrieval setup will beat resending the full text on every turn.
Why 500 tokens per page here and 400 on the PDF calculator?
Different questions need different assumptions. This page answers the capacity question, so it uses a dense page at about 500 tokens — the conservative figure that keeps you from overestimating what fits. The PDF summary calculator answers the cost question across mixed real-world documents, where an average nearer 400 tokens per page is more representative. Both are estimates; measure your own sample when the number matters.
Can I really use the whole window for the document?
Not quite. The window is shared between your instructions, the document, the conversation and the model's answer, so plan on filling around 70–80% of it with source material at most. On a 200k-token model that means treating roughly 150k tokens as the practical document ceiling, not 200k — and less again if you want several turns of follow-up questions.
Does page size or formatting change the count?
Considerably. A double-spaced manuscript page carries far fewer tokens than a dense two-column journal page, and slides or forms with heavy white space fewer still. Tables, footnotes and code blocks push the count up sharply. If your documents share a consistent layout, measure a few of them once and use your own tokens-per-page figure instead of a generic one.
Curious where these numbers come from? Read our pricing methodology.