Multiply the document’s word count by about 1.33 and you have a solid token estimate — a 10,000-word report is roughly 13,000 tokens. If you only know the page count, assume around 650 to 700 tokens per page of normal prose, then adjust up for dense legal or technical pages and down for slides. The document token cost estimator does this from a word, character or page count and turns it straight into a dollar figure for the model you’re using.
The two rules that get you close
You don’t need a tokenizer to plan. Two approximations cover most cases:
- ~1.33 tokens per word. English averages a little over one token per word, because longer or rarer words split into multiple tokens. Word count × 1.33 ≈ token count.
- ~4 characters per token. If you have a character count instead, divide by four. A 40,000-character document is roughly 10,000 tokens.
Both are estimates, and they drift. Code, JSON, and languages that don’t use spaces the way English does break into more tokens per word. Numbers and punctuation-heavy text push the ratio up too. For plain prose, though, these rules land within a few percent — fine for costing a job before you run it.
Page density changes everything
Page count is the least reliable proxy, because a “page” holds wildly different amounts of text depending on the document:
| Document type | Words per page | Tokens per page (≈1.33×) |
|---|---|---|
| Slide deck | 50–150 | 65–200 |
| Marketing / prose | ~500 | ~665 |
| Report / article | 500–650 | 665–865 |
| Legal / contract | 700–900 | 930–1,200 |
| Dense technical / code | 800–1,000+ | 1,060–1,330+ |
A 20-page slide deck and a 20-page contract can differ by 5× in tokens. So if accuracy matters, get a word or character count — most editors and PDF readers show one — rather than trusting the page total.
From tokens to cost
Once you have a token estimate, cost is straightforward. It has two parts:
- Input tokens — the document you send in, plus your prompt.
- Output tokens — whatever the model generates back (a summary, extracted fields, answers).
Cost = (input tokens × input rate) + (output tokens × output rate). Input and output are priced separately, and output is usually 3 to 5 times more expensive per token, so a big document with a short summary is cheaper than a small document with a long generated answer.
A worked example
Say you want to summarise a 40-page contract.
- At ~850 tokens per legal page, that’s about 34,000 input tokens.
- Add a 500-token prompt → ~34,500 input tokens.
- The summary you get back is ~800 output tokens.
On a model priced around $3 per million input and $15 per million output:
- Input: 34,500 × $3 / 1,000,000 = $0.104
- Output: 800 × $15 / 1,000,000 = $0.012
- Total: ~$0.12 for one pass.
Cheap for one document — but multiply by a few thousand contracts, or by every page of a document you re-send on each question, and it adds up fast. That re-sending is where costs quietly balloon: if you ask ten questions and resend the whole contract each time, you pay the 34,000 input tokens ten times over.
Estimate before you commit
The point of estimating up front is to avoid surprises at scale. A single document costing a few cents feels free; ten thousand of them is a real invoice, and a workflow that re-sends context on every turn multiplies it again. Run the numbers first with the document token cost estimator, which converts words, characters or pages into tokens and a cost for your chosen model.
If throughput matters as much as cost — how long a big document takes to process — tokens per second explained covers the speed side. And if you’re sending documents to a reasoning model, note that its hidden “thinking” tokens add to the output bill; why reasoning models cost more breaks down that extra charge.
