Free AI Token Counter: Paste, Count, and Price Your Prompt
Estimated at four characters per token, the same rule the calculator and the optimizer use. Exact counts vary by a few percent between tokenizers. Counted in your browser; nothing is uploaded.
A token counter tells you how many billable units your text will consume before you send it to an API. The counter above is free and private: paste any prompt, document, or code file and the count updates live as you type. There is no signup and no upload. It runs entirely in your browser, so proprietary prompts and confidential documents never leave your machine.
Why two counters disagree
Exact counts vary slightly by model because each provider uses its own tokenizer: OpenAI's GPT models, Anthropic's Claude, and Google's Gemini all split text a little differently. For English prose, the 4 characters per token rule used here lands within roughly 10 to 15% of the true count, which is plenty for budgeting. Code, JSON, and non-English text tokenize less efficiently, so expect real counts to run higher there.
What a token actually is
Not a word and not a character. Tokenizers are built by finding the sequences that occur most often in a large sample of text and giving each one an id, so common words end up as a single token while rare ones are assembled from several pieces. A frequent word costs one token; an unusual technical term, a brand name or a misspelling gets broken into fragments and costs several. This is also why the leading space matters: in most tokenizers a word preceded by a space and the same word at the start of a line are different tokens.
The practical consequence is that text you find dense is not necessarily text the model finds dense. Ordinary prose compresses well. A wall of UUIDs, base64, minified JSON or a stack trace does not, because none of those sequences appeared often enough in the training sample to earn short ids. That is the mechanism behind the rule of thumb below, and behind the cases where it breaks.
The tokens you are billed for but never pasted
This is the gap that surprises people when the invoice arrives. Counting the prompt you wrote counts a fraction of what you send. On every single call the API also receives your system prompt, the JSON schemas for any tools or functions you have defined, any documents your retrieval step pulled in, and the entire conversation so far, because the API keeps no memory between calls and the history has to be re-sent to exist at all.
That last one compounds. A twenty-message conversation is twenty calls, and the twentieth carries all nineteen turns that came before it, so a chat that feels like a series of short exchanges bills like a series of increasingly long documents. Tool schemas are the other quiet cost: a handful of well-documented functions can outweigh the user's actual question several times over, and they are sent whether or not the model calls any of them. If you want a count you can budget from, paste a full realistic request rather than the message you would type.
Where the four-characters rule breaks
It holds well for English prose and poorly elsewhere, always in the same direction: the estimate runs under the truth. Source code, JSON, XML and anything punctuation-heavy tokenize denser than prose, so a file of code costs more tokens than its character count suggests. Languages written in other scripts cost considerably more per character again, and text in a script with little representation in the training sample can approach one token per character. If you are budgeting a non-English or code-heavy workload, treat any character-based estimate, including this one, as a floor rather than a forecast, and run a sample through the provider's own tokenizer before committing to a number.
Counting is the diagnosis, not the cure
What separates this from a plain token counter is what happens next. The same count drives the cost calculator, which prices your prompt across every major model at your chosen scale, and the prompt optimizer, which shows how many of those tokens you can delete without changing what the model does. Counting tokens tells you the size of the bill; cutting them is how you lower it.
Two cautions on acting on a count. Input and output are priced separately, and output is usually the more expensive of the two, so a large input count is not automatically where your money is going. And if the text you are looking at is a fixed prefix you send on every call, it may already be billing at the cache-read rate, which is a fraction of the standard rate on the 32 of 40 models that publish one. Deleting cached tokens saves proportionally less than deleting fresh ones. Auditing a real usage export is the way to find out which of those you are dealing with.