LLM token counter
Paste a prompt, document or code. See its token count per tokenizer family and what it costs as input on every model. Everything runs in your browser.
The exact OpenAI tokenizer (about 1 MB) loads when you start typing.
This text is largely Korean, Japanese or Chinese. CJK text uses several times more tokens per character than English, and the gap between tokenizers is larger than for English, so treat non-OpenAI numbers as rough.
Cost of this text as input
| Model | Tokens | Once | × 1,000 |
|---|
Input only, standard price, no caching or batch discount. Long-context rates apply automatically when the text crosses a model's threshold. For output, caching and agent loops use the calculator.
How each count is made
| Tokenizer family | Ratio to o200k | Basis |
|---|---|---|
| OpenAI (o200k_base) exact | 1.00× | Exact count with o200k_base, the encoding tiktoken maps to GPT-5.x models. OpenAI has not published the tokenizer for GPT-6 models, so for those it is the closest public reference. Source |
| Claude 4.7 and later | 1.30× | Anthropic: Claude 4.7 and later models use a newer tokenizer that "produces approximately 30% more tokens for the same text". Applied on top of the Claude 4.6 estimate. Source |
| Claude 4.6 and earlier | 1.00× | Assumption: about the same as o200k_base. Anthropic does not publish its tokenizer; use the free token counting endpoint for exact numbers. Source |
| Gemini | 1.00× | Assumption: about the same as o200k_base. Google's own rule of thumb is about 4 characters per token for English; use the countTokens API for exact numbers. Source |
| xAI, DeepSeek, Mistral | 1.00× | Assumption: about the same as o200k_base. These providers do not publish a browser tokenizer; their usage reports are the source of truth. |
Only the OpenAI count is exact. The others are planning estimates: a provider's own tokenizer can count the same text noticeably differently, especially for code, non-English text and unusual formatting. If the cost decision is close, count a sample with the provider's own token-counting API.
CJK vs Latin text
Token counts depend heavily on the script. Counts below are exact o200k_base results for short samples:
| Sample | Characters | Tokens | Characters per token |
|---|---|---|---|
| English prose | 148 | 31 | 4.77 |
| JavaScript | 102 | 28 | 3.64 |
| Korean | 74 | 40 | 1.85 |
| Japanese | 53 | 38 | 1.39 |
| Chinese | 35 | 25 | 1.40 |
The common rule of "about 4 characters per token" fits English, but in these samples Korean, Japanese and Chinese average 1.5 characters per token. Budget non-English workloads with a real count.
FAQ
Is the OpenAI count exact?
It is an exact o200k_base count, computed in your browser with the open-source gpt-tokenizer library. o200k_base is the encoding tiktoken maps to GPT-5.x models. OpenAI has not published the tokenizer for GPT-6 models, and chat formatting adds a few tokens per message, so treat API usage numbers as final.
Why are Claude counts higher for newer models?
Anthropic states that Claude 4.7 and later models use a newer tokenizer that produces approximately 30% more tokens for the same text. The counter applies that ratio. For exact numbers, use Anthropic's free token counting endpoint.
Is my text sent anywhere?
No. Counting and cost calculation run entirely in your browser. The tokenizer file is downloaded once from this site and nothing you paste is uploaded.
Why does Korean, Japanese or Chinese text use more tokens?
Tokenizer vocabularies are built mostly from English and code, so CJK text splits into more pieces per character of meaning. In the samples on this page, English runs about 4.8 characters per token and Korean about 1.9.
Tokenizer: gpt-tokenizer 3.4.0 (MIT, license), served from this site.