Token Counter
Exact counts from the real BPE encodings, running in your browser — shown next to what the four-characters-per-token rule would have predicted. That rule is wrong in both directions, and only one of them is dangerous.
Free · No signup · Runs entirely in your browser
Exact token counts from the real BPE encodings — the same tables the models use, running in your browser. Shown next to what "one token is about four characters" would have predicted, because that rule is wrong in both directions and the direction is what matters.
The four-character rule underestimates this text by 19%. That is the dangerous direction: an underestimate is what overruns a context window in production, after the prompt has already been assembled. Text like this — non-English script, long identifiers, base64, hashes — fragments into far more tokens than its character count suggests.
Against a context window
| Window | Used | Remaining | Copies that fit |
|---|---|---|---|
| 128k | 0.07% | 127,910 | 1,422 |
| 200k | 0.04% | 199,910 | 2,222 |
| 1M | 0.01% | 999,910 | 11,111 |
Everything here runs locally — the encoding tables are downloaded to your browser the first time you edit the text, and nothing you paste is sent anywhere. That download is about a megabyte for the current models, which is why it waits until you need it rather than loading with the page.
Two caveats. This counts the tokens in your text, not the tokens in your API call — chat requests add a small per-message overhead for role markers, and tools or system prompts count too. And output tokens are usually priced higher than input, so a single per-million figure is a floor rather than a bill.
Context windows are a budget, and prompts grow fastest when nobody is watching them. If you are building largely on your own, Tekk turns what you want into specs your coding agent can actually execute.
What a token is
The unit a model actually reads. Text is split by a byte-pair encoding into pieces shorter than a word and longer than a character. Common words are one token, rare words split into several, and a leading space is normally attached to the word that follows it.
There is no formula. The split depends on tables learned from a training corpus, which is why an exact count requires running the real encoding rather than estimating — and why this page ships those tables instead of approximating.
The rule of thumb, measured
Everyone repeats that one token is about four characters. Measured against o200k_base:
| Content | Chars/token | What ÷4 predicts |
|---|---|---|
| English prose | 5.19 | 33% too high |
| TypeScript | 4.13 | 3% too high |
| JSON | 4.30 | 9% too high |
| Japanese | 1.73 | 55% too low |
| UUIDs | 1.78 | 54% too low |
Two things fall out of that table, and both are worth knowing.
The rule is wrong in both directions. It is not a conservative approximation. On English it overestimates by a third and on Japanese it underestimates by more than half — and only one of those is dangerous. Overestimating wastes budget and understates how much you can fit. Underestimating overruns the context window, in production, after the prompt has already been assembled.
Code is not the problem. The usual assumption is that code tokenizes badly. It does not — TypeScript sits at 4.13, closer to the rule than English prose is. What actually breaks it is non-English script and long unbroken identifiers: UUIDs, hashes, base64 blobs, and the kind of verbose camel-case names that read well and tokenize terribly.
The encoding matters too
The sample loaded above is 90 tokens under o200k_base and 100 under cl100k_base — the same text, an 11% difference, purely from which model you are targeting.
| Encoding | Models |
|---|---|
o200k_base |
GPT-4o, GPT-5, o-series |
cl100k_base |
GPT-4, GPT-3.5 Turbo, text embeddings |
Newer encodings have larger vocabularies, so they generally need fewer tokens for the same text — and the gain is largest exactly where the old ones struggled, which is non-English content.
Why the page pauses before your first keystroke
Because it is downloading real tokenizer tables — roughly 1 MB gzipped for o200k_base, 0.43 MB for cl100k_base.
That is a lot to send to someone who only wanted to read the page, so it is not sent. The count shown before you type is computed at build time on the sample text, and the tables are fetched by dynamic import on your first edit, one encoding at a time.
The alternative — estimating from character counts — would make the page instant and wrong, which for a tool whose entire value is exactness is not a trade worth making.
Two things this does not count
The envelope. Chat completions add a small per-message overhead for role markers, and system prompts, tool definitions and function schemas all count against the same window. This is the token count of your text; the API call is a little larger.
Output. Completion tokens are usually priced several times higher than input tokens, so the cost figure here is a floor. If you are budgeting a feature rather than a single call, estimate the response length separately and price it at the output rate.
How it works
- 1
Paste anything
A prompt, a document, a file of code. This token counter runs the actual encoding tables the models use — o200k_base for current OpenAI models, cl100k_base for the GPT-4 era — so the number is the number, not an estimate.
- 2
Compare it to the rule of thumb
The count sits beside what "one token is about four characters" would have predicted, with the error and its direction. On the sample above the rule underestimates by 19%, which is the direction that overruns a context window rather than the one that merely wastes budget.
- 3
Check it against a context window
How much of a 128k, 200k or 1M window your text uses, and how many copies would fit. Useful when you are deciding how many documents to stuff into a single call.
Frequently asked questions
- What is a token?
- The unit a language model actually reads, and the thing a token counter measures. Text is split by a byte-pair encoding into pieces shorter than a word and longer than a character — common words are a single token, rare ones split into several, and a space is normally attached to the word that follows it.
- How many characters are in a token?
- It depends entirely on the text, which is the point of this page. English prose runs around 5.2 characters per token, TypeScript about 4.1, JSON about 4.3, Japanese about 1.7, and UUIDs about 1.8. Any single rule of thumb has to be wrong somewhere across that range.
- Is the four-characters-per-token rule accurate?
- It is wrong in both directions and the direction matters, which is the reason to use a token counter rather than arithmetic. On English prose the rule overestimates by roughly a third, which just wastes budget. On Japanese and on long identifiers it underestimates by more than half — and an underestimate is what overruns a context window in production, after the prompt has already been assembled.
- Does code use more tokens than prose?
- Fewer per character, and the common intuition is backwards. TypeScript sits at about 4.1 characters per token against English prose at 5.2, so code is denser in tokens but close to the rule of thumb. What actually breaks the rule is non-English script and long unbroken identifiers such as UUIDs, hashes and base64.
- Which encoding should an openai token counter use?
- o200k_base for GPT-4o, GPT-5 and the o-series; cl100k_base for GPT-4, GPT-3.5 Turbo and the text embedding models. Any openai token counter has to pick one, and the difference is not cosmetic - the sample on this page is 90 tokens under one and 100 under the other, so the wrong choice puts you out by around 11%.
- Does this gpt token counter work for Claude or Gemini?
- Not exactly. Anthropic and Google use their own tokenizers, and this gpt token counter ships OpenAI's. The counts are usually in the same neighbourhood, so it is a reasonable estimate for sizing, but treat it as approximate for anything other than an OpenAI model.
- Why does a gpt token counter give different ratios for different text?
- It depends entirely on the text. An openai token counter that reports one ratio for everything is hiding the variance: English prose runs around 5.2 characters per token, TypeScript about 4.1, Japanese about 1.7.
- Do you store the text I enter?
- No. This token counter runs entirely in your browser. The encoding tables are downloaded to your machine on your first edit and the counting happens locally after that — nothing you paste is sent to a server, nothing is logged, and there is no account. Worth knowing before you drop a real prompt or a customer document into a web form.
- Why does the page take a moment the first time I type?
- Because it is fetching the real BPE tables — about a megabyte for o200k_base, less for cl100k_base. They load on your first edit rather than with the page, so reading costs nothing. The count you see before that is computed at build time on the sample text.
- Do the tokens in my API call match this number?
- Close, but slightly under. Chat requests add a small per-message overhead for role markers, and any system prompt, tool definitions or function schemas count too. Treat this as the token count of your text and add a little for the envelope.
- How do I estimate cost from a token count?
- Multiply by the price per token and divide appropriately — the field on this page takes a price per million, which is how providers quote it. Remember output tokens are usually priced higher than input, often several times higher, so a single rate gives you a floor rather than a bill.
- How do I reduce the number of tokens in a prompt?
- Cut examples before you cut instructions, since few-shot examples are usually the largest block by far. Strip formatting you added for human readability, avoid pasting whole files when a function will do, and be aware that verbose identifiers and deeply nested JSON cost real tokens for no benefit to the model.
- Why is this free, and what is Tekk?
- Tekk is a spec-driven development platform for people building software with AI coding agents. This tool costs us nothing to run, and context windows are a budget that prompts quietly overrun when nobody is watching. No signup, no run limit, no upsell inside the tool.
Want a real spec for what you’re building?
Drop a sentence. Tekk grounds it in your actual code and turns it into an executable plan.
Free to try · Connect GitHub during signup