What the checker does
A model’s context window is the most text it can handle in one request, measured in tokens. Paste your text or add files, and the checker counts the tokens for each model’s tokenizer. It then compares that number with the model’s published limits and tells you whether it fits, how much of the window it uses, and how many parts you would need if it does not.
On most models your prompt and the model’s answer share the window. So the checker keeps a number of tokens free for the reply (8,000 by default) and tests your text against what is left:
Some providers publish two numbers. OpenAI’s GPT-6 models accept up to 922,000 input tokens inside a 1,050,000-token total. Most Gemini models list a 1,048,576-token input limit and a separate 65,536-token output limit. Gemini 4 Argon, however, shares one 1,048,576-token window between input and output. The checker uses whichever rules the provider states.
Exact counts, estimates and the “Tight” result
For OpenAI models the token count is exact: the page runs the real o200k_base tokenizer in your browser. Anthropic, Google, Mistral, xAI and DeepSeek do not offer browser tokenizers, so their counts are estimates with a likely range. The LLM token counter explains how each estimate is made.
| Result | Meaning |
|---|---|
| Fits | Even the high end of the estimate fits, with the answer reserved |
| Tight | The estimate fits, but the high end of its range does not. Check with the provider’s own token counter before relying on it |
| Too big | The estimate alone is over the limit. The checker shows how many parts you would need |
| No limit published | The provider does not publish this model’s window |
Worked examples
A 300-page book. A typical novel of about 100,000 words is roughly 130,000 tokens in o200k_base. With 8,000 tokens reserved, it fits every model with a window of 256,000 tokens or more. GPT-4o mini (128,000 tokens) has 120,000 tokens of room, so the book needs 2 parts there.
A big codebase dump. Say you paste 3.2 MB of source code. Code runs about 3.5 characters per token in o200k_base, so that is roughly 900,000 tokens. It fits GPT-6.1 Sol’s 922,000-token input limit, but only just. Claude’s current tokenizer produces more tokens for the same text (about 30% more, by our estimate), so the same dump is probably too big for Claude’s 1M window even though the window looks larger. Grok 4.7’s 500,000-token window would need 2–3 parts.
A long chat history. Every turn of a conversation is sent again with each new message. Fifty turns averaging 600 tokens add up to 30,000 tokens before the newest question, which fits everywhere. But if your app also attaches a 150,000-token document to every turn, smaller models drop out quickly.
Tips when text does not fit
- Strip the noise. Web pages and PDFs carry menus, footers, page numbers and repeated headers. Converting them to clean Markdown with document to Markdown often cuts 20–50% of the tokens.
- Send only what the task needs. For a question about chapter 3, send chapter 3.
- Split and summarise. Process each part separately and combine the summaries in a final request (often called map-reduce).
- Check the price before you go big. A full 1M-token prompt costs real money on every request. The AI API cost calculator shows the bill, including long-context surcharges.
- Leave a margin. System prompts, tool definitions and images also use tokens. Keep 5–10% spare.
Limits and accuracy
Window sizes come from each provider’s official model pages, on the date shown under the table. Providers change limits with new model versions, and some charge more for very long prompts. A filled window can also hurt quality: models tend to pay less attention to the middle of very long inputs. When the result is close, confirm it with the provider’s own counting endpoint: Anthropic’s count_tokens and Gemini’s countTokens are both free to call.
Your text and files are read in your browser and never uploaded. PDF text is extracted with PDF.js on your device. Scanned PDFs have no text layer, so run them through image to text first.