Token Counter
Paste any text to see its exact token count and what it would cost as input across 45 models. Everything runs in your browser — the text is never uploaded. OpenAI counts are exact; other providers are labelled as estimates rather than passed off as measurements.
Pricing verified 2026-08-16 · no account · no logging
Loading tokenizer…
Characters per token, by content type
The "1 token ≈ 4 characters" rule is an English-only heuristic. Measured with
o200k_base:
| Content | Chars / token | Implication |
|---|---|---|
| English prose | 4.28 | The baseline every rule of thumb assumes |
| Code | 3.65 | Whitespace and symbols cost more than they read |
| JSON payloads | 3.24 | Long field names are billed on every request |
| Chinese / Japanese / Korean | 1.42 | ~3× the cost of English for the same meaning |
Measured on representative samples with o200k_base. Your text will vary — paste it above
for the actual number.
Frequently asked questions
How many characters are in a token?
It depends entirely on the language. English averages about 4.3 characters per token with the o200k_base tokenizer. Chinese, Japanese and Korean average closer to 1.4 characters per token. Code and JSON land in between, around 3.2–3.7. The common rule of thumb "1 token ≈ 4 characters" is only true for English prose and badly underestimates cost for CJK text.
Why does the same Chinese text cost 3× more than English?
Because tokenizers are trained predominantly on English text, so English words compress into single tokens while CJK characters often consume one token each — sometimes more. A sentence carrying identical meaning therefore costs roughly three times as much in Chinese as in English. If you serve a CJK-language product, this dwarfs most differences in sticker price between providers.
Does the tokenizer differ between models?
Yes, and it matters. Current OpenAI models use o200k_base; older GPT-4 and GPT-3.5 models use cl100k_base, which is substantially less efficient on CJK text — in our tests, 55 tokens versus 36 for the same Chinese sentence, a 53% difference. Anthropic documents that Claude 4.7 and later produce roughly 30% more tokens for the same text than earlier Claude models.
Are these counts exact?
For OpenAI models, yes — OpenAI publishes its BPE vocabularies and this tool runs the real encoder in your browser. For Anthropic, Google, xAI and DeepSeek, no exact browser-runnable tokenizer is published, so those figures are estimates based on o200k_base as a proxy, scaled by documented tokenizer factors where available. Every estimated row is labelled as such. Treat them as roughly ±15%.
Is my text uploaded anywhere?
No. The tokenizer runs entirely in your browser and the text never leaves your device. There is no account, no logging of input, and no server-side processing. You can verify this by opening your browser network tab while typing.
How do I reduce token usage?
In rough order of impact: enable prompt caching so repeated prefixes are billed at about 10% of base input price; trim system prompts and tool schemas, which are re-sent on every single request; prefer structured short field names in JSON payloads; and for bulk work, use the Batch API for a 50% discount. Switching to a cheaper model is often the smallest of these levers, not the largest.