LLM token counter
The real tokeniser, running in your browser. Not characters divided by four, which is wrong exactly when it matters.
Counted in this browser. Never uploaded.
Tokens o200k_base
0
Exact, tokenised in your browser
- Characters
- 0
- Words
- 0
- Chars / token
- —
What this prompt costs
| Model | Tokens | Input cost | Context used |
|---|---|---|---|
| GPT-5OpenAI | — | — | — |
| GPT-5 miniOpenAI | — | — | — |
| GPT-4.1OpenAI | — | — | — |
| GPT-4.1 miniOpenAI | — | — | — |
| GPT-4oOpenAI | — | — | — |
| GPT-4o miniOpenAI | — | — | — |
| GPT-4 TurboOpenAI | — | — | — |
| GPT-3.5 TurboOpenAI | — | — | — |
| Claude Opus 4Anthropicapprox | — | — | — |
| Claude Sonnet 4Anthropicapprox | — | — | — |
| Claude Haiku 3.5Anthropicapprox | — | — | — |
| Gemini 2.5 ProGoogleapprox | — | — | — |
| Gemini 2.5 FlashGoogleapprox | — | — | — |
Prices are USD per million input tokens, as published on 2026-08-25. Vendors reprice without notice, so check before you budget on these.
Four characters per token is a lie you can afford until you cannot
The rule of thumb is close enough for English prose and badly wrong for everything else. The gap is widest precisely where the bill is largest.
Language models do not read characters or words. They read tokens, produced by a byte pair encoding that was trained to give common sequences short representations. In English text a token is usually most of a word, which averages out near four characters.
Feed it something that is not English prose and the average collapses. A UUID is not a common sequence, so it becomes a long run of tiny tokens. Nested JSON spends tokens on punctuation that carries no meaning. A camelCase identifier splits at every capital. Urdu, Arabic, Japanese and Hindi routinely cost two to three times more tokens than the same content in English, which is a real and underdiscussed cost asymmetry.
Try it on the samples
The four sample buttons above are chosen to make the spread visible. English prose lands near four characters per token. The code and JSON samples land closer to three. The non-Latin sample is denser still. Same tool, same tokeniser, wildly different economics.
Where this tool will mislead you
It prices input only. Output is billed separately and usually costs four to five times more per token. A short prompt producing long answers will have a trivial input cost and a serious bill.
Anthropic and Google figures are approximations. Their tokenisers are not published in a form a browser can run, so those rows count with an OpenAI encoding as a stand-in and are labelled approx. Treat them as the right order of magnitude, not as an invoice.
Real requests carry more than your text. System prompts, tool and function definitions, prior conversation turns and image content all consume tokens. Measuring one message tells you what that message costs, not what the call costs.
Prices go stale. They are hand-maintained here and dated on the page for exactly that reason.
Terminology
- Token
- The unit a model actually reads and is billed on. Usually part of a word.
- BPE
- Byte pair encoding. The algorithm that turns text into tokens by repeatedly merging the most frequent adjacent pair, learned from training data.
- Encoding
- A specific trained vocabulary.
o200k_basefor GPT-4o, GPT-4.1 and GPT-5;cl100k_basefor GPT-4 Turbo and GPT-3.5. - Context window
- The maximum tokens a model can hold at once, covering your input and its output together. Exceeding it is an error, not a truncation you can ignore.
- Input and output pricing
- Billed separately and at different rates. Output is nearly always the more expensive of the two.
Questions about tokens
How many characters are in a token?
For ordinary English prose, roughly four. That is where the rule of thumb comes from and it is the reason so many token counters just divide by four.
It stops being true almost everywhere else. Source code, JSON, long identifiers, heavy punctuation and any non-Latin script all tokenise far denser, often two characters per token or worse. A prompt full of UUIDs and nested JSON can cost twice what the rule of thumb predicts, which is exactly the case where the number mattered.
Is this count exact?
For the OpenAI models, yes. It runs the real BPE tokeniser (o200k_base or cl100k_base depending on the model) in your browser, which is the same tokeniser the API uses.
For Anthropic and Google models it is an approximation, and every affected row is labelled. Those vendors use their own tokenisers, and no browser-runnable implementation is published, so this counts with the nearest OpenAI encoding as a stand-in. Expect the real figure to differ, sometimes by 10–20%.
Does my text get uploaded?
No. The tokeniser runs in the page and the text never leaves your machine. There is no server to send it to; this site is static files.
That is the practical reason to use this rather than a hosted token counter. The prompts worth measuring are usually the ones carrying customer data, internal documents or unreleased code, and pasting those into someone else's website to count them is a poor trade.
Why does the page take a moment to show an exact count?
Because the tokeniser is genuinely large. The o200k_base rank table is about 2MB, and cl100k_base another 1MB. Loading either before you have typed anything would make the page slow for everyone, including people who only wanted to read it.
So the page ships with no tokeniser and fetches one the moment you first type. Until it arrives you see a character-based estimate, clearly marked as an estimate. After that it is cached for the rest of your session and every keystroke is instant.
What is o200k_base?
The byte pair encoding used by GPT-4o, GPT-4.1 and the GPT-5 family. It has roughly 200,000 tokens in its vocabulary, which is where the name comes from.
cl100k_base is the older one, about 100,000 tokens, used by GPT-4 Turbo and GPT-3.5. A larger vocabulary generally means fewer tokens for the same text, particularly for non-English content, so the same prompt is usually cheaper to send under o200k_base.
Does the cost include the response?
No. This prices input tokens only, because that is the part you can measure before you send anything.
Output is billed separately and usually much higher, often four to five times the input rate. If your prompt is small and your responses are long, output will dominate the bill and this figure will look reassuringly small while being nearly irrelevant.
Why does the same text cost different amounts on different models?
Two independent reasons, and they compound. Models are priced differently per million tokens, which is the obvious one. But models also tokenise differently, so the same text is a different number of tokens depending on the encoding.
That is why the token column here is not a single figure for every row.
How current is the pricing?
As published on 2026-08-25. It is hand-maintained, and vendors reprice without notice, so treat it as a guide rather than a quote and confirm against the vendor before committing to a budget.
If a figure here is out of date, tell me and it gets corrected.
How this works
Tokenisation uses js-tiktoken, a JavaScript port of OpenAI's tiktoken, with the published o200k_base and cl100k_base rank tables. The encoding is loaded on first use rather than on page load, because the rank tables are several megabytes and the page should open instantly for someone who only wants to read it.
Context window sizes and per-token prices are transcribed from each vendor's published pricing page on 2026-08-25. Anthropic and Google do not publish a browser-runnable tokeniser, so those token counts are approximations and are marked as such in the table rather than presented as exact.
Nothing you type is transmitted anywhere. If a price or context limit here is wrong, tell me and it gets fixed.