Someone on the team asks for a cost estimate and reaches for a round number: call it 500 tokens a page, multiply by the corpus, done. It feels defensible because it is arithmetic. It is also where the estimate quietly detaches from the model you are actually going to serve. The honest answer to “how many tokens per page” is that there isn’t one — not a portable one. A token is not a word and not a page; it is a unit defined by the specific tokeniser a specific model uses. The same page of text can produce meaningfully different token counts under GPT-4’s cl100k_base, Llama 3’s SentencePiece vocabulary, or DeepSeek’s byte-pair merges. Reason in pages and you are estimating in a unit the serving path never sees. Reason in tokens measured against the deployed tokeniser and the downstream cost math becomes something you can sign off on. How many tokens per page, roughly? For dense English prose in a standard book or article layout, a page runs on the order of 500 to 750 tokens with most modern subword tokenisers — that is a planning heuristic, not a benchmarked constant, and it is the number to distrust the moment your content stops being clean prose. A “page” is a layout concept; tokens are a linguistic-plus-encoding concept, and the mapping between them bends with everything that changes the character stream underneath. Here is the useful version of the rule of thumb, with the caveats attached where they belong: Content type Approx. tokens per page Why it diverges Dense English prose ~500–750 Baseline; well-covered by subword vocabularies Sparse / formatted prose (headings, lists) ~300–500 Whitespace and short lines waste page area, not tokens Source code ~800–1,200 Indentation, symbols, and identifiers fragment into many tokens Tables / structured data ~700–1,400 Delimiters, repeated numerics, and cell boundaries inflate counts Non-Latin scripts (e.g. CJK, Cyrillic) highly variable Byte-level fallbacks can emit several tokens per character These ranges are an observed planning pattern from LLM sizing work, not a published benchmark; treat them as the starting hypothesis you verify, not the answer you ship. The table is deliberately wide in places. That width is the point: a corpus that is 30% code and tables can carry roughly twice the tokens-per-page of one that is clean prose, and no page count captures that. Why do token-per-page ratios vary so much? Four forces move the ratio, and they compound. Language. Subword tokenisers are trained on a corpus, and their vocabulary is efficient for whatever dominated that corpus — usually English. A common word like “the” is one token; a rarer word, an inflected form in a morphologically rich language, or a non-Latin script may fall back to multiple subword or even byte-level tokens. When this issue arises in practice, an English-optimised tokeniser processing German, Turkish, or Chinese can spend two to three times the tokens per unit of meaning. Formatting and whitespace. Tokenisers encode whitespace, newlines, and repeated spaces as tokens. Heavily indented or bulleted content — the kind that looks sparse on the page — can carry more tokens per visible word than dense prose, because the layout characters are not free. Code. Source code fragments badly under tokenisers built for natural language. Identifiers like getUserAccountBalance split into several tokens, punctuation is dense, and indentation repeats. Code routinely tokenises at well above the prose rate. Tables and structured data. Delimiters, column headers, and repeated numeric strings each cost tokens, and tables pack many of them into a small visual area. A single dense table can out-tokenise a page of prose. If you want the mechanism one level down — why a token is not a character and how the character-to-token ratio itself shifts — we walk through it in how many characters per token and what that means for inference cost, and the closely related characters, tokens, and inference cost explainer. This article is the layer above: converting documents into a defensible token forecast. How do I measure tokens against my model’s actual tokeniser? Stop estimating and run the tokeniser. Every serious model ships one, and running it over a representative sample of your own corpus is the single highest-value hour in the sizing exercise. The method is boring on purpose: Pull the exact tokeniser the deployed model uses. For OpenAI models, that is tiktoken with the model’s encoding (cl100k_base, o200k_base). For open-weight models — Llama, Mistral, DeepSeek, Qwen — load the tokeniser from Hugging Face transformers with AutoTokenizer.from_pretrained(model_id). Do not substitute a “close enough” tokeniser; the vocabularies differ and so will the counts. Sample your real corpus, stratified by content type. Pull representative documents across each bucket that matters — prose, code, tables, each language. A sample skewed toward clean prose will produce an optimistic ratio. Encode and count. Run each sample through the tokeniser, record tokens, and divide by pages (or documents, or requests — whatever your cost model’s denominator actually is). Compute per-bucket ratios, then weight by your corpus mix. The blended figure is your defensible tokens-per-page. Keep the per-bucket numbers; they are what let you re-forecast when the content mix shifts. The whole loop is a short script. The reason it matters is that it collapses the error bar: a rule-of-thumb figure can be off by a wide margin on a mixed corpus, while a measured pass against the real tokeniser typically lands within a few percent of production — an observed pattern from sizing engagements, not a guaranteed bound, but a reliable one. How token count drives cost-per-request and context sizing Token count is not one input among many — it is the unit LLM inference cost is denominated in. Priced APIs bill per prompt token and per generated token. Self-hosted serving is subtler but the same relationship holds: prompt tokens set the prefill compute, generated tokens set the decode steps, and together they set how much of the KV cache and context window each request consumes. Two distinct quantities fall out of a good token estimate: Cost-per-request — prompt tokens plus expected generated tokens, priced at your per-token rate (API) or amortised serving cost (self-hosted). Context window to provision — the largest prompt you must support, which sets the KV-cache memory footprint and constrains how many requests you can batch on a GPU at once. Underestimate tokens-per-page and you under-provision context, forcing truncation or spillover to a larger, costlier model tier. Overestimate and you over-provision memory, shrinking your batch size and raising cost-per-request for no benefit. The context window is expensive in ways that are easy to miss on a spec sheet — we unpack the memory and latency mechanics in what LLM context windows actually cost at inference. This token forecast is the sizing input that feeds an inference unit-economics model — the framework that turns per-request token counts into cost-per-request and monthly spend. Get the tokens wrong and every downstream number inherits the error. How an accurate estimate changes batching and prompt caching Two operational levers depend directly on token accuracy, and both quietly break when the estimate is a guess. Batching. Serving throughput on a GPU depends on how many requests you can hold in flight, which depends on how much KV-cache memory each request’s tokens consume. If your real prompts are 1,000 tokens but you sized for 500, your batch windows are half as effective as planned, and tail latency degrades under load exactly when it matters. Sizing batch windows correctly starts with knowing the token distribution, not just the mean. Prompt caching. Caching reused prefixes — system prompts, retrieved context, few-shot examples — only pays off if a large, stable fraction of your tokens are actually repeated. If most of your per-page tokens are unique document content, the cache hit rate is low and the engineering to maintain it is wasted. Whether prompt caching earns its keep is a token-distribution question, and you cannot answer it from a page count. Routing between model tiers has the same character — the decision hinges on measured token profiles, which is the logic behind how model routing cuts LLM inference cost. FAQ How many tokens per page? For dense English prose, roughly 500 to 750 tokens per standard page with modern subword tokenisers — a planning heuristic, not a fixed constant. Code, tables, formatted layouts, and non-Latin scripts push the figure well outside that range, so the honest answer is that you measure it against your own content rather than assume it. How do I convert a page or document count into an accurate token count for a given model? Run a representative, content-type-stratified sample of your corpus through the exact tokeniser the deployed model uses, compute per-bucket tokens-per-page ratios, then weight them by your actual content mix. The blended figure is your defensible estimate. Do not multiply a page count by a generic constant — that skips the model-specific and content-specific variation that dominates the answer. Why do token-per-page ratios vary with language, formatting, code, and tables? Tokenisers are trained on a corpus and are efficient for whatever dominated it, usually English; other languages fall back to more subword or byte-level tokens. Formatting, whitespace, and indentation are encoded as tokens too, and code and tables pack dense punctuation and delimiters into a small visual area. Each of these changes the character stream the tokeniser sees, so identical page area yields very different token counts. How do I measure tokens against the actual tokeniser my deployed model uses? Load the model’s own tokeniser — tiktoken for OpenAI encodings, AutoTokenizer.from_pretrained for open-weight models like Llama, Mistral, or DeepSeek — and encode a real sample of your corpus. Never substitute a “close enough” tokeniser, because vocabularies differ and so do the counts. The whole loop is a short script and typically brings the estimate within a few percent of production. How does token count drive inference cost-per-request and context-window sizing? Cost is billed per prompt token and per generated token, so token count is the direct unit of inference cost; prompt plus generated tokens set cost-per-request. The largest prompt you must support sets the context window and therefore the KV-cache memory footprint, which constrains batch size. Underestimating forces truncation or a costlier model tier; overestimating wastes memory and shrinks batches. How does an accurate tokens-per-page estimate affect batching and prompt-caching decisions? Batch throughput depends on how much KV-cache memory each request’s tokens consume, so an accurate token distribution is what lets you size batch windows correctly and keep tail latency in check. Prompt caching only pays off when a large, stable fraction of tokens is reused, which is a token-distribution question a page count cannot answer. Both levers quietly underperform when the estimate is a guess. What error margin should I expect from a rule-of-thumb tokens-per-page figure versus a measured one? A generic rule-of-thumb figure can be off by a wide margin on a mixed corpus — enough to produce a 2x cost surprise after launch when the content is code- or table-heavy. A measured pass against the real tokeniser typically lands within a few percent of production. This is an observed pattern from sizing work, not a guaranteed bound, but the gap between guessing and measuring is consistently large enough to justify the short script. The uncomfortable part of tokens-per-page is that the number you want is stable only within a fixed content mix — the day your corpus starts ingesting more code, PDFs with tables, or a second language, your blended ratio drifts and so does your cost forecast. That is why the defensible artifact is not a single number but the per-bucket ratios plus the script that produced them. When the token estimate needs to become a trustworthy per-request and monthly-cost figure on your serving path, that is the work an [inference cost audit](Inference Cost-Cut Pack) does, and it is where our broader R&D engagement work tends to start. The failure class to name up front: a page-count guess that understates context length and cascades into batching, caching, and cost decisions built on a number the model never agreed to.
