AI Token Counter

Most token counters hand you one fuzzy number and call it a day. The problem is that there is no single token count for a piece of text. Each model family splits it its own way, and the gaps get wide once you leave plain English. So this counter estimates all of them at once. Paste your prompt and you get a side-by-side count for GPT-4o, GPT-4 and 3.5, both Claude tokenizers, Llama 3, and Gemini, a colored token-by-token breakdown so you can see where the splits fall, and a running cost for whichever model you pick. Everything happens in your browser, so the prompt you paste, which is often private text or unreleased code, never leaves your machine.

Be clear on one thing up front: this gives you a close estimate rather than running the vendor's exact encoder. A real tokenizer runs a trained vocabulary we can only approximate from the outside. For ordinary English the estimate lands within a few percent of the true count, and it drifts more on dense code or non-Latin scripts. Right up against a context limit and need the exact figure? Use the official tokenizer for your model. For everything else, a fast local estimate you watch update as you edit is the number you actually reach for.

1. Paste, type, or drop in your text. Type directly, paste a prompt, drop a text file onto the box, or click Load file to pick one.
2. Read the headline count. The big number up top is the token estimate for the model you have selected, sitting next to the plain character and word counts.
3. Compare models. The table lists every family with its own estimate. Tap any row to make it the active model, and the headline number, breakdown, and cost all follow.
4. See the breakdown. The colored panel shows the text split into estimated tokens, each piece a different shade, so you can spot the long words, numbers, and punctuation that quietly inflate the count.
5. Price it. Enter your model's input price per 1,000 tokens and the cost column fills in for every model, so you can see what the same prompt would run on each.
6. Trim and recount. Cut filler, shorten variable names, drop context the model already has, and watch the number fall. It is a quick loop for tightening a prompt before you send it.

Every model family is trained with its own tokenizer and its own vocabulary. OpenAI's GPT-4o and o-series use a vocabulary called o200k, while GPT-4 and GPT-3.5 use the older cl100k. Anthropic, Google, and Meta each ship something different again. The same sentence gets carved into a different number of pieces depending on who built the encoder, and the counter reflects that by giving you a separate estimate per family instead of pretending one number fits all.

For plain English the families usually land within roughly 10 to 15 percent of each other. That gap widens fast for code, heavily punctuated text, numbers, and any non-English writing. Newer tokenizers are not always more efficient, either. Anthropic has documented that its recent Claude models, Opus 4.7 and later along with the Fable-tier models, use an updated tokenizer that produces meaningfully more tokens for the same text than the previous one. That matters for your bill: compare only the headline price between two versions and skip the token count, and a "cheaper" model can cost more per request because it counts more. Whenever you switch models, re-measure a few real prompts rather than trusting the old numbers.

The breakdown panel is the part that makes tokenization click. Instead of a single total, it paints each estimated token in an alternating color so the boundaries are visible. Common short words like "the" or "and" are a single token each. A leading space usually rides along with the word after it, so " tokenization" is one unit that starts with the space. Longer or rarer words break into two or three pieces. Numbers get chopped into groups of one to three digits, so a long order number is several tokens, not one. Punctuation, symbols, and emoji often cost their own token.

Try the three example buttons to feel the difference. English prose sits near the classic four-characters-per-token average, the code sample runs hotter as brackets, operators, and indentation each pull tokens, and the numbers-and-IDs line is the real eye-opener, spending far more than its length suggests. Boundaries in the panel are approximate, and on very long input the preview stops after a few thousand characters while the totals still cover everything. The panel shows where your tokens go more clearly than a raw count does.

Two hard limits in every model are measured in tokens, and both bite if you ignore them.

The first is the context window, the maximum tokens a model can handle in a single request. It has to hold everything at once: your system prompt, the conversation so far, the document you pasted, and the model's own reply. Go past the window and the request either fails or gets quietly truncated, which is how you end up with an answer that ignores the second half of what you sent. The size of that window varies enormously between models. Some frontier models offer hundreds of thousands of tokens, even a million, while faster or cheaper ones often sit near 128K or 200K. Because the window includes the response, never fill it completely with input, since you have to leave real room for the answer.

The second is cost. Providers bill per token and charge input and output separately, usually at different rates, with output typically the pricier side. Counting your input before you send lets you estimate the bill, compare models honestly, and catch an expensive prompt before it ships. On a batch job the difference between a tight prompt and a bloated one, multiplied across thousands of calls, is real money. Worth remembering: the counter measures the text you paste, which is your input floor. It cannot know how long the reply will be, and the reply is billed too. So treat the counted number as one input to a cost estimate, not the whole invoice.