PDF token limits by AI model: a practical reference (2026)

Every time you send a PDF to an AI model, you are working inside a token budget. Go over the limit and the model either refuses the input or quietly drops content. The tricky part: each model family has a different ceiling, and those ceilings keep changing as providers ship updates.

I keep this page updated. Every number below was checked on October 8, 2026 against the providers' own model pages: OpenAI, Anthropic and Google. If a provider has shipped something newer since then, trust their page over this one.

Current context windows (October 2026)

The page column assumes 250 to 500 tokens per page of dense text. Rows marked * are lower because Claude's current tokenizer produces more tokens for the same text (more on that below). The only reliable way to know your own number is to measure it.

An earlier version of this page listed GPT-4o at 128K and Claude 3.5 Sonnet at 200K. Those are no longer the current models, and the gap is the real news: almost every flagship model now takes around a million tokens. For most PDFs the question has moved from "will it fit?" to "what will it cost, and how well will the model use all of it?"

Cost has its own threshold, and it sits well below the window. Claude Haiku 5.5 bills a prompt over 100K tokens at five times its normal rate, the GPT-6 models double their input price above 272K, and Gemini 3.1 Pro goes from $2 to $4 per million above 200K. In all three cases the whole request is billed at the higher rate, not just the part over the line (see the Anthropic, OpenAI and Google pricing pages).

I left open-weight models like Llama and Mistral out. Their usable context depends on how and where you run them, so one number would mislead more than it helps.

Why these numbers are not what you can actually use

On most models the window is shared between what you send and what the model writes back, so a long answer comes out of the same budget as your document. Google lists Gemini's input and output limits separately. System prompts, conversation history, and tool calls take their share too.

A safe planning rule: assume you can use about 80% of the stated window for your document. For a 1M window, plan for roughly 800K tokens of actual PDF content.

One more catch: these are API limits. Chat apps can set their own caps on file size or context, so pasting a PDF into a chat window doesn't guarantee you get the full number.

Tokenizer differences across models

The same PDF doesn't cost the same number of tokens everywhere. The clearest example right now is Claude. Anthropic's model page says 1M tokens holds roughly 555K words on the tokenizer introduced with Claude Opus 4.7, while earlier models fit about 750K words in the same 1M. That's about 35% more tokens for the same text, and it's why the Claude 5.x rows above show fewer pages.

OpenAI's models page doesn't say which encoding the GPT-6 models use, so the o200k count in the Token Counter is an estimate for them, not an exact figure. Gemini has its own tokenizer too, and Google's token counting guide explains how to get an exact count from the API.

Non-English text usually costs more tokens per word than English, and how much more depends on both the language and the tokenizer. If your PDFs aren't in English, measure instead of estimating.

When to chunk versus when to send the full file

If your document fits comfortably within 80% of the context window, send it whole. Chunking introduces boundary problems and makes retrieval more complex.

If it does not fit, or if you are building a retrieval system that needs to serve many documents, chunk into segments sized for your embedding model (typically 256 to 1024 tokens per chunk).

Measure before you commit to a strategy

Run your actual PDF through a token counter before choosing a workflow. What looks like a 40-page document can easily be 25 000 tokens if it has dense tables, legal boilerplate, or non-English text.

If chunking is needed, the PDF Chunker splits with overlap and exports structured output directly from the browser.