What is a token counter?
Language models do not read characters or words — they read tokens: sub-word chunks produced by a tokenizer trained on enormous amounts of text. Token counts decide what a prompt costs, whether a document fits in a model's context window, and where a long text must be split for retrieval or summarisation. A token counter tells you that number before you send anything: paste the text, read the count.
Most counters on the web estimate — characters divided by four, words times one-point-three. Those ratios are tolerable for English prose and quietly wrong for everything else: code, other languages, JSON, emoji. This counter instead runs the real tokenizers in your browser — the actual byte-pair encoding tables the models themselves use — so the numbers beside each encoding are exact for the models named, not approximations with a confident face.
How to use this tool
- Paste or type your text into the box above — or upload a text file or drop one onto the box; the file is read in your browser and never sent anywhere.
- Read the two token counts. Use the one for your model's encoding: cl100k_base for GPT-4 and GPT-3.5, o200k_base for GPT-4o, GPT-4.1 and the o-series. The counts update as you type.
- Use the character, byte, word and line counts for everything tokens do not decide: length limits, storage size, editorial budgets.
- For a cost estimate, multiply the token count for your model's encoding by that model's published input price — and remember a chat API adds a small per-message formatting overhead that no text-only counter can see.
Two encodings, honestly labelled
OpenAI's models have used two tokenizers in recent generations, and this page reports both rather than picking one silently. cl100k_base serves GPT-4, GPT-3.5-Turbo and the text-embedding-3 models. o200k_base serves GPT-4o, GPT-4.1 and the o-series reasoning models; its larger vocabulary usually counts the same text a little lower, and noticeably lower on text cl100k handles awkwardly — several non-English languages, code with long identifiers, symbol-heavy content. Neither encoding says anything authoritative about Claude, Gemini, Llama or any other family's models: they tokenize differently, their vendors' counts are the only exact ones, and a page that printed a single unlabelled "token count" for all models would be misleading you. What transfers is the order of magnitude; what does not is the number.
Why the rough rules of thumb break
"One token is about four characters" survives because it roughly holds for ordinary English. Watch it fail: a JSON payload spends tokens on every brace, quote and colon; a line of code spends them on indentation alone; a Chinese character typically costs a token or more by itself in cl100k; a single emoji can cost several. The sample button loads a paragraph of plain English — compare its tokens-per-word against the same counts for a pasted code file or a paragraph in another language, and the need for a real tokenizer makes itself. When a context window or an invoice is on the line, exact beats approximate.
Examples
The sentence "Hello, world!" is 4 tokens in both
encodings — Hello, ,, world,
! — from 13 characters and 2 words. A typical English
paragraph runs at roughly 1.3 tokens per word. A dense JSON
object of the same character length can cost twice the tokens of
the paragraph, because its punctuation is structural and every
piece of it is billable. That spread — same characters, very
different counts — is the whole reason this tool exists.