Token counter

Every LLM cost calculator asks for a token count. This one measures it. Paste the system prompt, tool definition or document you actually send, pick a model, and see the count and what it costs per run — computed in your browser, nothing uploaded.

Measure a prompt

paste what you actually send — the count updates as you type

Every LLM calculator asks for a token count.
This one measures it.

This is an estimate, not a tokenizer. A real BPE vocabulary is 1–2 MB of WebAssembly — roughly ten times this site’s entire JavaScript budget — so the count is computed from a segment-aware heuristic rather than the model’s own vocabulary. It prices words, numbers, punctuation and CJK runs separately instead of assuming four characters per token, which is why the range moves with the kind of content you paste. For an exact figure, use your SDK’s token-counting endpoint.

Counting tokens on Bedrock

The count moves with the kind of content

The estimator segments the text and prices each run on its own terms: common short words are one token, long words split every four to five characters, digit runs split every two to three, symbol runs seldom merge at all, and CJK sits near one token per character. That is why a JSON tool definition and a paragraph of prose of the same length do not produce the same number — and why the range widens on structured and mixed content, where the estimator is least reliable.

The prompt prefix is what actually costs money

In an agentic loop the same system prompt and tool schema are re-sent on every step, so a prefix measured once here bills tens of thousands of times a day. With prompt caching those repeated tokens bill at roughly a tenth of the input rate. Send the measurement to the cost calculator to see the difference at your volume, or check which models support caching.

When you need the exact number

Use the Bedrock CountTokens API, or the token-counting endpoint in your provider SDK, for anything that has to be exact — context-window limit checks, quota alerts, billing reconciliation. An estimate is the right tool for sizing a prompt and comparing models; it is the wrong tool for an assertion in a test.

Questions

How many tokens is my prompt?
Paste it above. The count is estimated from a segment-aware heuristic: words, numbers, punctuation runs and CJK characters are priced separately rather than assuming four characters per token, and the result is shown as a range because BPE tokenization varies between model families.
Is this an exact tokenizer?
No. A real BPE vocabulary is 1-2MB of WebAssembly, roughly ten times this site’s entire JavaScript budget, so nothing is downloaded and nothing is uploaded — the text never leaves the browser. For an exact figure use the Bedrock CountTokens API or your SDK’s token-counting endpoint.
Why is "characters divided by four" wrong?
That rule of thumb is calibrated on English prose. Code carries far more punctuation and each symbol run tends to cost its own token, JSON is mostly delimiters, digits split aggressively, and CJK is close to one token per character. On those inputs chars/4 can be off by a factor of two in either direction.
Does the token count include the output?
No. This measures input tokens only, which is what you control by editing the prompt. Output tokens are billed at a higher rate on every Bedrock model — model both sides in the cost calculator.