How many tokens is a page of text?
A single-spaced page of English prose is about 650–700 tokens. Where that number comes from, context windows in pages, and when the rule breaks down.
The short answer: a single-spaced page of English prose is about 650–700 tokens. If you only need one number, use 670 and move on.
The longer answer is worth a few minutes, because “a page” is not a unit — it is a layout decision — and because the rule of thumb breaks in four specific, predictable ways that account for most of the surprise on people’s first invoice.
Where 670 comes from
For English text, one token averages about four characters, or about three quarters of a word. Inverting that: 1,000 words is roughly 1,330 tokens.
Then you have to pick what “a page” means:
| A page of… | Words | ≈ Tokens |
|---|---|---|
| Double-spaced manuscript | 250 | 335 |
| Single-spaced document, normal margins | 500 | 670 |
| Dense textbook or academic paper | 650 | 865 |
| Trade paperback | 300 | 400 |
The 500-word single-spaced page is the one most people mean, and it is the one worth memorising. A 300-page novel is therefore in the region of 120,000 tokens; a 20-page report around 13,000.
What a context window looks like in pages
Context windows are advertised in tokens, which makes them hard to feel. At 670 tokens per page:
| Context window | ≈ Pages | ≈ Words |
|---|---|---|
| 128K | 190 | 96,000 |
| 200K | 300 | 150,000 |
| 400K | 600 | 300,000 |
| 500K | 750 | 375,000 |
| 1M | 1,500 | 750,000 |
A 1M-token window really does hold a stack of paper about 1,500 pages tall — three or four average novels, or a mid-sized codebase. A 128K window holds a single long report and not much else once you have added a system prompt and room for the answer.
That last clause matters: the window is shared between what you send and what comes back. If you fill 127,000 tokens of a 128K window, there is no room left for a response.
The four cases where 670 is wrong
1. Code. Source code averages closer to three characters per token than four. Punctuation,
identifiers in camelCase or snake_case, and indentation all fragment. A 200-line source file
is often 2,000–3,000 tokens where the same word count of prose would be 1,300. Minified or
tightly-formatted code is genuinely cheaper than the pretty-printed equivalent.
2. JSON, CSV and other structured data. Every brace, quote, comma and colon is billable, and repeated key names are billed on every record. A 100-row JSON array with eight keys per row spends a large fraction of its tokens restating the same eight strings. Pretty-printing adds an indentation cost on top of that. For bulk data, CSV is usually the cheapest wire format simply because the field names appear once.
3. Non-Latin scripts. Chinese, Japanese and Korean run at roughly 1.5 characters per token. Those scripts pack more meaning into fewer characters, so it partly cancels out — but not entirely. In practice the same passage translated into Japanese or Chinese lands 1.5–2× higher in tokens than the English original. Cyrillic, Greek, Arabic and Devanagari sit between the two extremes and generally cost more than English.
4. Extracted PDF text. A PDF’s page count tells you very little. Extraction pulls in running headers and footers on every page, footnotes, page numbers, table cell fragments in whatever order the file stores them, and hyphenated line breaks that split words into pieces the tokenizer then has to fragment further. Scanned PDFs contain no text at all until they are OCR’d. A 40-page PDF can come out anywhere between 8,000 and 60,000 tokens.
For a real file, guessing is the wrong tool. The PDF token counter parses the document in your browser and gives you the actual number, page by page — nothing is uploaded.
What a page costs
Take a mid-range flagship rate of $2.00 per million input tokens:
| Volume | Tokens | Input cost |
|---|---|---|
| One page | 670 | $0.0013 |
| A 20-page report | 13,400 | $0.027 |
| A 300-page book | 201,000 | $0.40 |
| A full 1M context window | 1,000,000 | $2.00 |
Input is the cheap column. Output on the same model is commonly $12 per million — six times the input rate — so a 1,000-token answer costs $0.012, roughly what nine pages of input cost.
This is the single most common budgeting mistake: teams spend a sprint shortening prompts and leave response lengths untouched. If your workload is one long document in and one paragraph out, input dominates. If it is a short question in and a long generated document out, shortening the prompt barely moves the bill. The full pricing table lists input, cached input and output separately for every model for exactly this reason.
Estimate, then measure
Rules of thumb are for capacity planning — deciding whether a 128K or a 1M window is the right tier, or whether a corpus will fit at all. They are not for pricing a specific job.
When it is a specific job, paste the actual text or drop in the actual file: the token counter gives an exact BPE count for every GPT model and a labelled estimate for the models whose tokenizers are not public. The difference between 670 and the real number is usually small on one page and decidedly not small on ten thousand.
Put it to work: count tokens, measure a document with the PDF token counter, or compare rates on the LLM pricing page. All posts are on the blog index.