By J. Wren · Last reviewed 2026-10-13
Paste your prompt to count how many tokens it uses. Runs in your browser, nothing is sent anywhere. GPT models are counted exactly; Claude and Gemini are estimated.
Showing the 4-characters-per-token estimate. Start typing (or change the tokenizer) to load the exact counter.
The "tokens" figure becomes an exact count once the tokenizer has loaded; until then, and always in the last box, it shows the 4-characters-per-token estimate. Claude and Gemini use different tokenizers; treat the GPT count as an estimate for them.
LLMs don't read characters or words — they read tokens, chunks of roughly 4 English characters (about ¾ of a word). Punctuation, spaces and rare words split into more tokens. Different models (GPT, Claude, Gemini) use different tokenizers, so exact counts differ — by about one percent on English prose in our measurements, but by 20% or more on Chinese and code. For English the 4-characters-per-token rule is close enough for a rough cost estimate.
We measured this directly with the same tokenizers used above: English prose averages 5.15–5.23 characters per token, JSON about 2.65, and code about 3.74 — see Does 4 Characters Really Equal 1 Token? for the full breakdown by language and encoding.
The same fifty samples were also counted with Gemini's own countTokens endpoint on four Gemini model ids, and all four returned the same counts. Against o200k_base, Gemini needed 0.762 times as many tokens on Traditional Chinese and 1.226 times as many on Python code. See Gemini vs GPT Token Counts. The counter above still shows the 4-characters estimate for Gemini, not these counts.
Figure 1 — tokens needed for the same text, relative to o200k_base, by text type
How to read it: each group is one kind of text; o200k_base is the baseline (1.000, dashed line), and a longer bar means more tokens for the same characters, so a higher cost. Gemini figures are net of the 1-token overhead of the countTokens request and are identical on all four Gemini ids. Claude was not measured. Ten short segments per category, measured on 2026-10-13. Source and method: Gemini vs GPT Token Counts (Table 2) and measure_gemini_vs_gpt_tokens.results.json.
The heuristic holds for ordinary English prose. It degrades badly for everything else, and always in the same direction — more tokens than you expected:
| Content | Effect on token count |
|---|---|
| Plain English prose | Close to the estimate above |
| Code and JSON | Higher — indentation, braces, quotes and symbols each cost tokens |
| Non-English text | Much higher, sometimes several times, for scripts less represented in the tokenizer |
| Long identifiers, hashes, UUIDs | Very high — unfamiliar strings fragment into many small pieces |
| Numbers and tables | Higher; digits often split in ways that look arbitrary |
This matters most for non-English products, where a budget built on the English rule of thumb can be off by a wide margin in the wrong direction.
The same count drives three separate limits, which is why it is worth measuring once and reusing. Billing is per token for input and output. The context window is measured in tokens and is shared between your prompt and the response. And rate limits are frequently enforced in tokens per minute as well as requests per minute — see the API Rate Limit Calculator for which of the two binds first.
The exact counter above covers GPT models, using the same o200k_base and cl100k_base tables OpenAI's APIs bill against. For production budgeting on any model, the most reliable source is still the usage figures the API returns on every response, since that reflects what was actually billed — including parts you did not write, such as system prompts and tool definitions. For Claude and Gemini, where no public browser-side tokenizer exists, an estimate within 10–20% is fine for deciding whether a plan is affordable. It is not fine for enforcing a hard limit, where undercounting means requests fail in production.
Five short samples, counted with the exact tokenizer above — o200k_base and cl100k_base give identical counts on this plain-text input — against the 4-characters-per-token estimate:
| Sample | Characters | Tokens (o200k_base / cl100k_base) | 4-char estimate |
|---|---|---|---|
| "The quick brown fox jumps over the lazy dog." | 44 | 10 | 12 |
| "Please summarize the attached quarterly report in three bullet points, focusing on revenue, churn and headcount. Keep each bullet under 20 words." | 145 | 28 | 37 |
{"user_id": 48213, "plan": "pro", "renews_on": "2026-10-01", "seats": 12} | 73 | 34 | 19 |
def total(items): | 64 | 17 | 16 |
3f2504e0-4f89-11d3-9a0c-0305e82c3301 | 36 | 27 | 9 |
The pattern holds across content types: plain prose is over-estimated by the 4-characters rule, while JSON and identifier-like strings such as UUIDs are under-estimated by roughly 2–3×, because punctuation and unfamiliar substrings each cost a token of their own.
For GPT models, yes for the text itself. This tool counts tokens with OpenAI's own o200k_base tokenizer (GPT-4o, GPT-4.1 and the GPT-5 family) or cl100k_base (GPT-4, GPT-3.5), the same tables those APIs bill against — though the Chat API adds a few formatting tokens per message on top of the text you paste here. Claude and Gemini use different, non-public tokenizers, so their figure is only the 4-characters-per-token estimate — treat it as approximate.
APIs bill per token (input + output). Count your tokens here, then use an LLM API cost calculator to get the dollar figure.
Yes. Tokenizers are model-family specific, so the same paragraph produces different counts across providers, and sometimes across versions of the same family. The differences are usually small for English prose and larger for code and non-English text — enough to matter when a prompt sits near a context limit.
Related: LLM API Cost Calculator