LLM Token Counter

Know your token budget before you send

What a token actually is

Language models don't read characters or words — they read tokens, the sub-word chunks produced by a byte-pair-encoding (BPE) tokenizer. Common English words are usually one token each, while rare words, code identifiers and non-Latin scripts split into several. That's why "hello" costs one token but a UUID can cost ten, and why the same paragraph translated into another language often uses noticeably more tokens. As a rough rule of thumb, one token is about four characters of typical English prose — but the whole point of this counter is that you don't have to rely on rules of thumb.

Why the count differs between models

Every model family trains its own vocabulary, so the same text tokenizes differently in each. This tool runs the actual cl100k BPE tokenizer in your browser for the GPT figure, which makes that count exact, and derives calibrated estimates for Claude and Gemini, whose tokenizers aren't publicly available. The per-model list under the big number shows the spread — useful when you're comparing providers for a workload, since a prompt that fits one model's context window can overflow another's.

Budgeting prompts like an engineer

Token counts drive two real constraints: cost and context. For cost, multiply your expected requests by the input token count shown here — trimming a 2,000-token system prompt by a third saves a third of that spend at any scale. For context, remember the window must hold your prompt plus the model's answer, so leave headroom rather than filling it to the brim; retrieval snippets, chat history and few-shot examples are the usual places where prompts quietly balloon. Pasting your longest real-world prompt here before shipping is a thirty-second sanity check that prevents mid-conversation truncation surprises.

Step-by-step: how to count tokens and estimate cost

Paste or type into the text box on the left. The large number on the right updates about a tenth of a second after you stop typing; the label under it reads tokens (exact · cl100k) once the real GPT tokenizer has finished loading, and tokens (estimated) if it is still loading or blocked by an ad blocker. Below the headline number you get three quick stats — characters, words and lines — which are handy for comparing your count against the "four characters per token" rule of thumb and seeing how far your specific text deviates from it.

The table underneath lists seven models: GPT-4o, GPT-4 Turbo, GPT-3.5 Turbo, Claude 3.5 Sonnet, Claude 3 Haiku, Gemini 1.5 Pro and Gemini 1.5 Flash. Each row shows the token count for that model and the input cost at a typical public per-million-token price, printed to four decimal places (five for sub-cent amounts). To budget a whole workload, take one row's cost and multiply by your expected daily request volume — the tool deliberately shows single-request cost so that you can apply your own traffic numbers. To count a full chat transcript rather than a single prompt, paste the system prompt, every prior turn and the new user message together; that is what the API actually bills for on every call.

Real-world use cases

• Trimming a system prompt. Paste the prompt, note the count, then delete one paragraph at a time and watch the number. Teams routinely find that a 1,800-token prompt can lose a third of its tokens without losing any instructions, which compounds across every request.
• Sizing RAG chunks. When building retrieval pipelines, paste a representative document chunk to see how many tokens a 500-word passage really costs. That tells you how many chunks fit in the context window once you subtract the system prompt and the space reserved for the answer.
• Comparing providers. Paste the same prompt and compare rows: a Gemini 1.5 Flash request may cost roughly thirty times less than the same prompt on GPT-4o. The table makes the per-request difference concrete before you write any integration code.
• Checking localized content. Paste the English and translated versions of a UI string or help article side by side. Armenian, Georgian, Japanese or Arabic text typically uses two to four times more tokens, which matters when the same prompt template is served in many languages.

How the counter works under the hood

The GPT figure comes from the open-source gpt-tokenizer package, which ships the cl100k_base merge table used by GPT-4 and GPT-3.5. The page loads it as an ES module and runs the byte-pair-encoding algorithm on your text: the input is split into UTF-8 bytes, then repeatedly merged into longer pieces according to the ranked merge list until no more merges apply. The resulting array length is the exact token count OpenAI would bill for that text — with one caveat: the API adds a few tokens of chat formatting overhead per message, usually three to four per turn, which this counter does not include.

For Claude and Gemini, whose tokenizers are not public, the counter blends two signals: characters divided by a per-model ratio (3.8 for Claude, 4.0 for Gemini) and word count multiplied by 1.33, weighted 55/45. On ordinary English prose this lands within a few percent of the provider's own count; on dense code or non-Latin text expect a larger margin and treat the figure as a planning estimate rather than an invoice. If the exact tokenizer fails to load, the GPT row falls back to the same estimate and the label switches to estimated so you always know which kind of number you are looking at.

Further reading

For a deeper explanation of BPE vocabularies, context windows and why prices are quoted per million tokens, read LLM tokens explained. If you are pasting minified or beautified source into prompts, minify vs beautify shows how formatting changes token counts. Browse all guides for more.

Frequently asked questions