LLM Token Count Estimator
Estimate how many tokens a prompt will use, with character, word and line counts. Results are approximations, not exact tokenizer output.
How to use this tool
Steps for using the Token Estimator.
- Paste a prompt, document or code into the Text or prompt panel, click Open text file, or click Sample. The counts update as you type and nothing leaves your browser.
- Read the Estimate view: an approximate token count with a range from the lowest to the highest heuristic, the exact character, word, line and UTF-8 counts, and notes for code or non-Latin text.
- Switch to Sections to see which paragraphs use the most tokens (click one to select it in the editor), or to Chunks to split the text into pieces under a token limit with optional overlap for retrieval (RAG) — copy or download them.
- In Context window check, pick a size (4K–1M) or type your model's context size and the expected response length to see whether everything fits.
- In Cost estimate, enter your provider's input and output prices per million tokens and the number of requests to estimate the cost.
Example
English sentence
The quick brown fox jumps over the lazy dog.~12 tokens (range 11–12)
Characters: 44 · Words: 9 · Lines: 1 · UTF-8: 44 B
Characters ÷ 4: 11 · Words × 1.33: 12Common use cases
- Checking whether a long document plus instructions will roughly fit in a model's context window before sending it.
- Comparing the relative size of two prompt variants while iterating on wording.
- Budgeting how much room is left for retrieved context or conversation history in a RAG or chat application.
- Getting exact character, byte and line counts for a prompt that has to fit a field or API size limit.
- Explaining to teammates why non-English text or code uses more tokens than the same length of English prose.
How token estimates are calculated — and why they are approximate
Language models do not read characters or words; they read tokens produced by a tokenizer, usually a byte-pair encoding (BPE) or SentencePiece model trained on a particular mix of text. Common English words are often a single token, while rare words, numbers, URLs and identifiers are split into several pieces. Because every model family ships its own vocabulary, the same text can produce noticeably different token counts on different models, and the only exact answer comes from running that model's tokenizer. This tool deliberately does not pretend to replicate any specific tokenizer.
Instead it combines simple, documented rules of thumb and shows the spread. For prose, it calculates characters ÷ 4 and words × 1.33 (roughly 0.75 words per token), both commonly quoted approximations for English. If the text looks like code — at least 8% of non-space characters are brackets, operators or quotes — it adds characters ÷ 3, because symbols and indentation tend to break into many short tokens. When at least 30% of letters come from non-Latin alphabets such as Cyrillic, Greek, Arabic or Devanagari, it adds characters ÷ 2. The range runs from the smallest to the largest of these, and the headline estimate is the midpoint.
Chinese, Japanese and Korean characters are handled separately. These scripts do not separate words with spaces and each character carries more information, so tokenizers typically spend about one to two tokens per character. The tool counts each CJK character as 1 token at the low end and 2 at the high end and adds that to the estimate for the rest of the text. Words are counted as runs of non-whitespace characters, and CJK characters are excluded from the word count so they are not double-counted.
The exact figures are exact: characters counts Unicode code points (an emoji is one character, even though JavaScript's length counts it as two), bytes are the UTF-8 encoded size, and lines accept LF, CRLF or CR endings. The context window check uses the upper end of the range plus your expected output, so it errs on the side of caution. If you are close to a limit, measure with your provider's official tokenizer or token-counting endpoint before relying on the number.
Limitations
- Token counts are estimates from heuristics, not output from any real tokenizer, and can be noticeably off for unusual text such as base64, minified code or mixed scripts.
- Chat APIs add a few tokens of formatting per message that are not included here.
- Images, audio and tool definitions are not counted.
- Input is limited to 2 million characters.
Frequently asked questions
Why doesn't the estimate match the count from my model provider?
Each model family uses its own tokenizer and vocabulary, so the same text produces different token counts on different models. This tool uses general heuristics rather than any particular tokenizer. For an exact number, use your provider's tokenizer library or token-counting API.
Why is a token roughly four characters?
For typical English text, frequent words and word fragments are single tokens and average about four characters including the following space. It is a rule of thumb, not a law — code, numbers, rare words and other languages diverge from it, which is why the tool shows a range.
Why do Chinese, Japanese and Korean use more tokens per character?
These scripts have thousands of distinct characters and no spaces between words, so tokenizers often encode one character as one or more tokens. Per character that is several times more than English, although each character also carries more meaning.
What context window size should I enter?
Use the figure from your model's documentation. The default of 128,000 is only a starting value. Remember that the window usually has to hold both your prompt and the model's response.
Is my text sent to an AI model to count tokens?
No. All counting happens in your browser with plain JavaScript. Nothing is uploaded and no model is called.