Paste your prompt to estimate how many tokens it uses. Runs in your browser, nothing is sent anywhere.
Estimate uses the common heuristic of ~4 characters per token (English). Actual counts vary by model tokenizer — treat this as a close approximation for budgeting.
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 slightly different tokenizers, so exact counts differ, but the 4-characters-per-token rule is close enough for estimating API cost.
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.
For production budgeting, exact counts come from the provider rather than from any heuristic. Most APIs return usage figures on every response, which is the most reliable source because it reflects what was actually billed — including parts you did not write, such as system prompts and tool definitions. Some providers also expose a token-counting endpoint or an official tokenizer library for counting before sending.
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.
No — it's a heuristic estimate. For exact counts, use the model provider's official tokenizer. For budgeting API spend, this is accurate to within ~10–20%.
APIs bill per token (input + output). Estimate 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