Token Counter — Free Online Tool on Toolpile
Every tool you need, one place
PDF, Image, AI, Dev, and Business tools — free, private, no signup.
Toolpile uses cookies for analytics and ads. The tools themselves keep your files in the browser — that doesn't change. Read the full policy
PDF, Image, AI, Dev, and Business tools — free, private, no signup.
About Token Counter
Tokens, not characters or words, are what every commercial LLM bills on. Mis-estimating them by 30% — common when people use "chars / 4" — turns a $50 budget into a $65 bill. This tool runs the actual provider tokenisers in your browser (no API key, nothing uploaded), shows the count for every major model side by side, and adds the cost math.
A token is the unit a language model reads and writes. Modern LLMs use **byte-pair encoding (BPE)** or a close variant: the tokeniser starts with raw bytes and learns to merge frequent byte pairs into single tokens during training. Common English words become single tokens (`hello` = 1 token); rare or compound words split into pieces (`strawberry` = `straw` + `berry` ≈ 2-3 tokens depending on the encoder). Whitespace and punctuation are part of the encoding too — the leading space in ` world` is usually merged with the word after it.
Why this matters for billing: when you paste 1,000 English words into a chat box, you're sending roughly 1,300-1,500 tokens to OpenAI's o200k encoder, ~1,400 tokens to Anthropic's tokeniser, and a different count again to Google's character-rate model. The difference between providers is often 10-20%. The difference between English and Japanese can be 2-3× because non-Latin scripts compress less efficiently into BPE merges.
Rule of thumb that's *roughly* right for English prose: 1 token ≈ 4 characters ≈ 0.75 words. For code, JSON, or non-English text, this rule fails — sometimes badly. Always count the real tokens for anything you'll be charged for.
**OpenAI models (GPT-5, GPT-4o, GPT-4o-mini, o3)** use the `o200k_base` encoder loaded from the open-source `gpt-tokenizer` package. The encoder runs in pure JavaScript in your browser; the count is exact and matches what OpenAI's billing system charges. Older GPT-3.5/4 used `cl100k_base` (also open). Both encoders are deterministic, so you get the same number locally as the API would report.
**Anthropic models (Claude Opus 4, Sonnet 4, Haiku 4)** are approximated with the open `cl100k_base` encoder — Anthropic ships its own tokeniser only as a WebAssembly build that can't be constructed reliably in a browser bundle, so we fall back to a close, deterministic stand-in. Expect the Claude count to be within a few percent of the real value; for an exact figure the API exposes a `messages.count_tokens` endpoint that returns the count without spending tokens.
**Google Gemini and Meta Llama** are shown with a `chars / 4` heuristic in this tool — Google does not publish a public Gemini tokeniser file, and the Llama tokeniser exists (Hugging Face) but adding it would 5× the bundle size for marginal precision gain. For Gemini 2.5 Pro/Flash and Llama 3.1 70B the heuristic is within ±10% for English; for non-English or code-heavy input, treat the number as rough and verify against the provider's own counting endpoint before committing to a budget.
Loading the tokenisers happens once per page as a lazy JavaScript import. After load, every keystroke recomputes counts in <10 ms even for 100k-character pastes.
Every model has two prices: input tokens (what you send) and output tokens (what the model generates). Output is consistently 4-5× more expensive than input on most providers because it's the part the model actually computes — input is just read, output is sampled token-by-token through the full transformer stack. Estimating output tokens correctly is where most cost surprises come from.
This tool defaults to a 500-token output estimate. That maps to roughly 350-400 English words — appropriate for a typical chat reply. Long-form generation (an article, a code review, a structured JSON response with embedded reasoning) easily hits 2,000-4,000 output tokens; reasoning models like o3 or extended-thinking Claude can chew 10,000+ output tokens *internally* before producing the user-visible answer, and most providers bill for the internal tokens too. When budgeting, set the output estimate to your worst-case expected reply length, not the average.
The price-per-1M-tokens numbers in this tool reflect public list pricing as of 2026. Real bills are often lower (committed-use discounts, batch API at 50%, prompt caching at 90% off cached tokens) or higher (high-throughput tiers, regional surcharges). Use the per-call numbers shown here as a worst-case ceiling, not the final invoice.
Is this counter exact for OpenAI and Anthropic?
Yes for OpenAI (o200k_base via the open gpt-tokenizer package — bit-for-bit identical to the API's own counter, and what the provider's billing system charges). Anthropic models are approximated with the open cl100k_base encoder because Anthropic doesn't ship a browser-safe tokeniser for Claude 3+; the count lands within a few percent — verify against Anthropic's `messages.count_tokens` endpoint if you need the exact figure. Google Gemini and Meta Llama use a chars/4 heuristic that's within ±10% for English prose; for production budgeting on those providers, double-check via the provider's own counting endpoint.
Why does "strawberry" come out as multiple tokens?
BPE tokenisers learn merges from training data. Common short words get a single token; long or rare words get split. "strawberry" appears less often in training corpora than "straw" and "berry" individually, so the encoder breaks it into pieces. This is also why famous LLM failures like "how many r's in strawberry" exist — the model doesn't see individual letters, it sees the merged tokens.
How do I count tokens for non-English text?
Same way — paste it. But expect counts 1.5-3× higher than equivalent English. Non-Latin scripts (Chinese, Japanese, Arabic, Hindi) compress poorly into BPE because the encoder was trained mostly on Latin-script text. A 1,000-character Japanese essay can use 2,500-3,000 tokens; the same essay translated to English uses ~750 tokens. For multilingual workloads, this is the single biggest cost factor most teams underestimate.
Does the count include system prompts and tools?
Whatever you paste, this tool counts. Real API calls also charge for: the system message (often a hidden ~200-500 tokens of behaviour rules), every tool/function definition you attach (~100-300 tokens each), and any tool output messages in multi-turn calls. For accurate budgeting on agentic flows, count the entire serialised request body, not just the user message.
What about output reasoning tokens (o3, extended thinking)?
Reasoning models generate internal chain-of-thought that you don't see but pay for. OpenAI's o3 can consume 5,000-50,000 reasoning tokens to produce a few-hundred-token visible answer; Anthropic's extended-thinking mode is similar. The 'output tokens' line on your invoice includes those. When estimating output for a reasoning model, multiply your expected visible-reply length by 10-50× depending on task complexity.
Why are input prices so much lower than output prices?
Input tokens are processed in a single forward pass — fast and parallelised across the prompt. Output tokens are generated sequentially, one at a time, each requiring a full forward pass through the model. The output side dominates real GPU cost, so providers price it 4-5× higher. This is also why reducing your output (by capping max_tokens or asking for terser replies) saves more money than shrinking the prompt.
Are tokens uploaded anywhere?
No. The tokenisers run entirely in your browser via WebAssembly. There is no network request when you paste text or change the output estimate. You can verify in the DevTools Network tab — only the page itself loads.
How do I reduce token usage in my prompts?
Three biggest wins: (1) move static behaviour instructions into a cached system message — providers offer 90% discounts on prompt caching for the cacheable prefix. (2) Strip examples down — three good examples almost always beat ten redundant ones. (3) Use structured output schemas instead of free-form 'reply in JSON' instructions — schemas can save 30-50% on the schema-defining tokens vs. inline descriptions.