PDF-to-tokens estimator
Long documents are where LLM bills explode. Before you push a hundred-page PDF into a model, this tool tells you how many tokens it is, what that costs, and whether it even fits the context window — so you can choose intelligently between sending it whole, chunking it, or summarizing first.
How it works
You can estimate two ways. Paste the extracted text and the tool tokenizes it directly with a character-based heuristic. Or, for a quick sizing, enter the page count and words-per-page, and it estimates tokens from typical document density (about 1.33 tokens per English word). It then prices the input against your chosen model and shows the percentage of that model’s context window the document fills. Everything runs locally; nothing is uploaded.
Why token count matters before you send
When you pass a PDF to an LLM, you are paying for every input token on every API call. For a document that sits permanently in the prompt, the cost multiplies with each question you ask. A 100-page research report at roughly 650–750 tokens per page is in the range of 65,000–75,000 tokens. At typical input pricing for a current-generation large-context model, that adds up quickly if you are asking dozens of questions in a loop.
The context window check is equally important. A document that uses 90% of a model’s context window leaves little room for the conversation history, your instructions, and the model’s response. Retrieval-augmented generation (RAG) or document chunking exist precisely to address this: you embed the document once, then at query time retrieve only the two or three relevant chunks and send those, keeping each call to a few thousand tokens instead of tens of thousands.
Choosing a strategy based on this estimate
| Situation | Strategy |
|---|---|
| Document fits easily, queried once or twice | Send the whole document — simplest approach |
| Document fits but you will ask many questions | Summarize or chunk; resending 70k tokens repeatedly is expensive |
| Document exceeds the context window | Must chunk or use RAG; cannot send whole |
| Scanned PDF with no extractable text | OCR first; this tool cannot estimate image-only PDFs |
| Dense legal or technical text | Adjust words-per-page upward from 500 to 600–700 for a more accurate estimate |
The page-count estimate vs. pasted text
The page-count method is a planning heuristic. Real documents vary substantially: a slide deck with one sentence per slide averages far fewer tokens than a dense contract, and a page of mathematical notation tokenizes very differently from prose. For budget-critical runs — a multi-thousand-document batch, for example — paste the actual text from a representative page and multiply by page count, or use the model provider’s official tokenizer CLI to confirm the exact count.
Tips and notes
If a document fits comfortably in the context window and you only need to ask it one or two questions, sending it directly is simple and fine. If you will query it many times, the per-call cost of resending everything dominates — chunk it and retrieve only the relevant passages, or summarize once and reuse the summary. Scanned PDFs have no extractable text and need OCR first, which this estimate does not cover. Treat the token figure as a close estimate and confirm against the provider’s tokenizer for large or budget-critical runs.