Token Counter
See how many tokens your text uses in ChatGPT and other AI models, plus an estimate for Claude. Nothing leaves your browser.
Loading Token Counter… If nothing happens, please enable JavaScript.
Language models do not read characters or words, they read tokens: short chunks of text taken from a fixed vocabulary that the model was trained with. Prices, rate limits and context windows are all measured in tokens, so knowing how many a prompt uses tells you what a request will cost and whether a long document will fit. Paste text, a prompt or a source file into this counter and it tokenizes it with the same byte pair encoding tables OpenAI uses: o200k_base for GPT-4o, GPT-4.1, the o-series reasoning models and the GPT-5 family, and cl100k_base for GPT-4 and GPT-3.5 Turbo. Alongside the token count you get characters, words, lines and the average number of characters per token, which is a quick way to see how efficiently a given language or format is encoded.
Frequently asked questions
Is my text uploaded anywhere?
Which encoding should I choose?
Is the GPT token count exact?
How accurate is the Claude estimate?
How do I get the exact Claude token count?
What does the chars per token ratio tell me?
What is the context window bar?
Why are the same words split differently in different places?
Can I count tokens in a file?
About Token Counter
The token view underneath shows exactly where the boundaries fall, with each token on an alternating background and an option to display the numeric token IDs instead of the text. This is useful when a prompt behaves oddly: you can see that a leading space is part of the next word, that a long number is split into groups of three digits, or that a word in Portuguese or Japanese needs several tokens where the English equivalent needs one. Code, JSON and minified text tend to use more tokens per character than prose, and the ratio figure makes that visible. To keep the page fast, only the first 2,000 tokens are drawn, while the counts always cover the whole input.
Claude models use their own tokenizer, and Anthropic does not publish it in a form that can run in the browser. The Claude figure shown here is therefore an estimate, calculated from the o200k_base count with a factor range, and it is labelled as such. Newer Claude models (Opus 4.7 and later, and the Fable models) use a tokenizer that produces noticeably more tokens for the same text than older Claude versions, so treat the upper end of the range as the safer planning number and use Anthropic's count_tokens API endpoint when you need the exact count. Everything runs locally: the tokenizer tables are loaded from this site, and your text is never sent anywhere.
Byte pair encoding began as a compression trick
The algorithm behind these tokenizers was not invented for language models. Philip Gage described byte pair encoding in 1994 in The C Users Journal as a simple data compression method: find the most frequent pair of adjacent bytes, replace it with a byte that does not occur in the data, and repeat until no pair is common enough to be worth it.
In 2015 Rico Sennrich and colleagues adapted the idea for neural machine translation. Instead of compressing a file, they used the same greedy merging to build a vocabulary of subword units, so a translation model could handle rare words and names by assembling them from familiar pieces. OpenAI's GPT-2 in 2019 moved the process down to raw bytes, which meant any string, in any language or with any emoji, could be encoded without an unknown token.
That byte-level design is why a single emoji can take several tokens and why a word may be split in surprising places: the vocabulary reflects which byte sequences were common in the training data, not how people think about words. It is also why vocabularies keep growing, from about 50,000 entries in GPT-2 to around 100,000 in cl100k_base and 200,000 in o200k_base, each step letting common text fit into fewer tokens.