LLM Token Calculator
Every cost estimate starts with a number nobody knows: how many tokens is my text? Paste it below — counted in your browser from the providers' own rules of thumb, shown as an honest range, carried into any calculator in one click.
For anyone about to price an AI workload who doesn't know their token counts yet — paste real text, get an honestly-ranged estimate from the providers' own rules of thumb, then carry the number into any cost calculator in one click.
Model prices from OpenRouter · updated 2026-07-13
01 Paste your text
Counted entirely in your browser — the text is never uploaded, logged, or put in the URL. The carry-forward links below contain only the token count.
02 Estimated tokens
chars ÷ 4 → 125 · words × 4⁄3 → 110
500 characters · 82 words
Carry the number into a calculator
03 Typical sizes (same official ratio)
Price the number you just counted
Estimation method: OpenAI's published rules of thumb (1 token ≈ 4 characters of English; 100 tokens ≈ 75 words), computed as two independent estimates with the min–max shown as the range; CJK characters counted at 1–2 tokens each. For an exact count on one specific model, use that provider's own tokenizer page. All computation runs in your browser; nothing is uploaded.
How the math works
Every cost calculator on this site asks for token counts, and that's exactly where most estimates stall — nobody knows offhand how many tokens their prompt is. This page turns text into that number: paste anything (a system prompt, a sample document, a typical user message) and it's estimated instantly, entirely in your browser. The text never leaves the page and never enters the URL.
The method is deliberately the providers' own published rules of thumb, not a guess: OpenAI documents that one token is roughly 4 characters of common English text, and that 100 tokens is roughly 75 words. Those give two independent estimates — this page computes both and reports the min–max as a range. The sample prompt loaded by default runs 82 words / 500 characters, which the two methods put at 110–125 tokens (midpoint 118).
A range is the honest answer, because exact counts differ by provider tokenizer — the same text tokenizes differently on GPT, Claude and Gemini, typically within ±10–20% of these estimates for English. For cost decisions that spread is noise: being 15% off on tokens moves your bill 15%, while the effects the calculators expose (caching, history replay, hidden reasoning, batch discounts) move it 2–10×. Precision theater wouldn't change any decision this number feeds.
Non-English text needs care: Chinese, Japanese and Korean tokenize far denser per character — typically 1–2 tokens per character depending on tokenizer generation, where English runs about one token per four characters. This page counts CJK characters separately at that 1–2× band and widens the range accordingly. For exact counts on a specific model, paste the same text into that provider's own tokenizer page; for cost planning, the range here is enough.
Once you have the number, carry it forward: the buttons below the estimate open the cost calculators pre-configured — as input tokens per request, as a cacheable system prefix, or as a line in the whole-stack calculator. The link carries only the token count, never your text. All math runs client-side with tested code.
Frequently asked questions
How are the tokens estimated?
Two methods from OpenAI's own documentation, computed side by side: characters ÷ 4 ("one token is ~4 characters of English") and words × 4⁄3 ("100 tokens ≈ 75 words"). The range shown is the min–max of the two; the midpoint is the number carried into the calculators. CJK characters are counted separately at 1–2 tokens per character.
Why a range instead of an exact count?
Because there is no single exact count — GPT, Claude and Gemini each tokenize the same text differently (typically within ±10–20% for English). A range from published rules of thumb is honest; a single number would be fake precision. For cost planning the spread is negligible next to the 2–10× effects the calculators model.
Does my pasted text leave the browser?
No. The estimate is computed entirely client-side — nothing is uploaded, logged, or stored, and the text never enters the URL. The carry-forward links contain only the token count.
What about Chinese, Japanese or Korean text?
CJK text tokenizes much denser per character than English — typically 1–2 tokens per character, varying by tokenizer generation. This page detects CJK characters and widens the range to that band. Non-English alphabetic languages (Spanish, German, etc.) usually land near the English ratios, slightly higher.
How do I get an exact count for one specific model?
Use that provider's own tokenizer page (OpenAI and others publish interactive tokenizers) — that's the ground truth for a single model. This page's job is different: a fast, provider-neutral estimate good enough to price a workload, with one-click carry into the cost calculators.
What do I do with the number?
Carry it into a calculator: as input tokens on the LLM API cost calculator, as a cacheable prefix on the prompt-caching calculator, or as the system prompt / user message in the whole-stack AI cost calculator. Each button opens the page pre-configured with your count.