LLM Token Counter
Count tokens for any text using the real tokenizers, with a per-token breakdown showing exactly where a passage splits. Nothing is transmitted.
Paste text to count tokens
Cost estimates update live across all major models
What a token actually is
Language models do not read characters or words. They read tokens — subword fragments produced by a byte-pair encoding (BPE) tokenizer that was trained on a corpus by repeatedly merging the most frequent adjacent pairs.
The result is that common words are single tokens while rare ones fracture. "the" is one token. "tokenization" is typically two or three. A misspelling, a UUID, or a long identifier can be one token per character.
This has a direct consequence people find surprising: the model cannot reliably see individual letters. Asking how many r's are in "strawberry" is hard not because the model cannot count, but because it never sees s-t-r-a-w-b-e-r-r-y — it sees something like ["str", "aw", "berry"]. The letters are not in its input at all.
The same mechanism explains why models are weak at reversing strings, at character-level wordplay, and at arithmetic on long numbers — a number splits into arbitrary chunks that do not align with digit positions.
Token density by content type
The "one token ≈ 0.75 words" rule is calibrated on English prose and is badly wrong elsewhere. Approximate multipliers relative to English:
| Content | Tokens | Why |
|---|---|---|
| English prose | ~0.75 per word | The baseline every rule of thumb assumes |
| Source code | 1.5–2× prose | Punctuation, indentation and camelCase identifiers all split |
| JSON | ~2× prose | Braces, quotes and repeated key names dominate the payload |
| Base64 / hashes | ~1 per 2–3 chars | No learned merges apply to random-looking strings |
| UUIDs | ~1 per 2 chars | Roughly 16–20 tokens for one 36-character UUID |
| Chinese / Japanese | ~1–1.5 per character | Far denser than the per-word intuition suggests |
| Hindi / Tamil / Bengali | 3–4× English | Frequently near one token per byte — a real cost and fairness issue |
| Emoji | 2–4 each | Multi-codepoint sequences such as 👨👩👧👦 cost considerably more |
The script disparity is worth naming: the same passage costs several times more in Hindi than in English, both in money and in context window consumed. Newer tokenizers have narrowed the gap but not closed it.
Why your bill differs from any counter
- Chat template overhead —A chat request is not raw text. Role markers, message delimiters and any system content are added by the API before tokenization, adding a small fixed overhead per message — typically 3–7 tokens each.
- Different families, different tokenizers —The same text genuinely produces different counts on different model families. A counter can only be exact for the tokenizer it is using.
- Tool and function definitions count —JSON schemas for tools are serialised into the prompt and billed as input tokens on every single call, whether or not a tool is used. A large tool schema is a permanent per-request cost.
- Output tokens are usually the expensive half —Output is typically priced at 3–5× input. A cost estimate driven only by prompt length will be badly low.
- Reasoning tokens may be invisible —Reasoning models generate internal tokens that are billed but not always returned. They can dominate the bill on hard problems.
About
The Token Counter uses the gpt-tokenizer library (MIT-licensed, pure JavaScript) to count exact GPT tokens via the cl100k_base and o200k_base encodings. Claude token counts use a calibrated approximation (words × 1.33) and Gemini uses characters ÷ 4 — both are disclosed inline. The tool shows token count, character count, word count, and line count for the input text, plus a results table listing all 11 supported models (July 2026 lineup) with their tokens, input cost estimate, output cost estimate, and a context-window utilization bar. All processing is local — your text never leaves the browser.
How to use
- 1 Paste or type your text in the editor on the left.
- 2 Instantly see the token count, character count, and word count update for all models.
- 3 Review the per-model table showing exact or approximate token counts and cost estimates.
- 4 The context bar shows what percentage of each model's context window your text occupies.
- 5 Note: GPT models use exact tiktoken counts; Claude and Gemini use disclosed approximations.
- How is the token count calculated?
- For OpenAI models (GPT-5.x, o3) we use BPE encoding via gpt-tokenizer (MIT license, runs entirely in your browser) — an approximation, since OpenAI's newest tokenizer revisions are not published as JS libraries. Claude uses words × 1.33 (Anthropic's published approximation). Gemini uses characters ÷ 4. All approximations are disclosed inline.
- Why do different models give different token counts for the same text?
- Each model uses a different tokenizer with a different vocabulary. GPT uses BPE (Byte Pair Encoding), Claude uses a similar BPE vocabulary but different merges, Gemini uses SentencePiece. The same word may tokenize differently — for example, "tokenization" could be 1 token in one vocabulary and 2 tokens in another.
- What is the context window?
- The context window is the maximum number of tokens a model can process in a single request — both your prompt (input) and the generated response (output) must fit within it. Exceeding the context window causes truncation or an API error.
- Is my text sent to any server?
- No. All tokenization runs in your browser using a WebAssembly/JavaScript library. Your text is never sent to Anthropic, OpenAI, Google, or any other service.
In-depth guides
More in AI Tools
See all ai tools.