LLM Token Counter: Estimate Tokens, Context and Cost

The LLM token counter estimates how many tokens a piece of text will consume, then compares that count against the context windows of common models and calculates an illustrative input cost. Paste a prompt, a document, a transcript or a code file, pick a model, and read the result. The counting runs in your browser.

The important caveat is in the name: this is an estimate, not a provider's tokenizer. It models how byte-pair vocabularies tend to split text, and it is usually within a few percent on English prose. It will be less accurate on code, unusual identifiers and some non-Latin scripts. For budgeting and capacity planning that is fine; for exact billing, use the provider's own tokenizer.

#What the result includes

• Token estimate, plus character, word, sentence and paragraph counts.
• Tokens per word, which is the quickest signal that the text is unusual.
• Non-ASCII character count, for text where a characters-per-four rule breaks down.
• Context usage against the selected model, in tokens and as a percentage.
• Headroom, or the number of tokens left before the window is full.
• Input and output cost at the model's listed per-million-token prices.
• A comparison table across every configured model.

The comparison is the useful part for model selection: the same prompt can fit comfortably in one window and not fit at all in another.

#How to count tokens

1. Open the LLM token counter.
2. Paste the text. The limit is 2,000,000 characters.
3. Pick a model from the list, or choose Something else and enter a context window.
4. Press Count.
5. Read the estimate, the context percentage and the comparison table.

If you choose a custom model, the context window must be a whole number between 1 and 10,000,000 tokens. Custom models are treated as self-hosted unless configured otherwise, so the cost shows as zero.

#How the estimate is calculated

The counter segments text the way a byte-pair vocabulary tends to:

• Short English words count as one token; longer words split roughly every five characters.
• Digit runs count as one token per three digits.
• Each mark of punctuation counts as one token.
• Spaces attach to the following word rather than counting separately.
• Line breaks count as one token.

That is more realistic than dividing characters by four. The familiar rule works on plain English but drifts on code, long German compounds, identifiers and CJK text. The result notes when the characters-per-four estimate would have been off by more than ten percent, and why.

CJK text is counted at roughly one token per character, which is close for Chinese and Japanese but tends to undercount Korean. Accented Latin text is handled correctly because the segmenter works on characters, not bytes.

#Reading the context number

A context window is a hard limit on a single request. It covers everything the model sees and produces:

• The system prompt.
• The conversation history.
• Retrieved documents.
• The user's message.
• The model's answer.

People often count only the document and forget the rest. If a 128,000-token window is 90 percent full before the answer, there is very little room left. A useful habit is to keep the input well below the window and reserve space for the response.

The comparison table flags models where the text does not fit at all. For those, the options are chunking, summarising, or moving the material into a retrieval step rather than sending it whole.

#Cost estimates

The tool multiplies the token count by each model's listed input price per million tokens, and separately shows what the same count would cost as output. Output is usually several times more expensive than input, which is why long generations dominate a bill.

Treat these numbers as a planning aid, not an invoice. Prices change, tiers and caching alter the effective rate, and providers count tokens slightly differently. The configured prices are visible in the comparison table and are easy to update; always confirm against the provider's current pricing page before committing to a budget.

#Common problems and fixes

The count differs from the provider's. Expected. This is an estimate built from segmentation rules, not the provider's vocabulary. Small differences are normal; large ones usually mean code, identifiers or a script the heuristic handles less well.

My text fits according to the table but the API rejects it. The count covers only the text you pasted. The system prompt, chat history and the model's output also consume the window. Leave headroom.

The cost looks too low. You are probably looking at input only. Output tokens are priced separately and are usually more expensive.

A model is missing. The list is configured in the application. Choose Something else and enter its context window to get the context calculation; the cost will show as self-hosted unless configured.

The estimate is way off for code. Code has punctuation, indentation and identifiers that split differently from prose. Use the provider's tokenizer when exact code counts matter.

A very large document is slow. The browser has to segment the text. Two million characters is the limit, and performance depends on the device.

I need to reduce the count. The system prompt optimizer removes padding and duplicated rules, and the persona builder keeps prompts structured rather than bloated.

#Tips for working within a context window

• Reserve output space. A full window leaves no room for the answer.
• Count the whole request, not just the document. System prompt and history are part of the budget.
• Move stable reference material to retrieval. Sending the same long document on every request is a recurring cost.
• Shorten examples before removing rules. Examples are often the most effective part of a prompt.
• Watch tokens per word. Above roughly 1.6, the text is dense with code, punctuation or long words; below 1.0, it is probably digit-heavy.
• Use caching where the provider offers it. A stable prefix can be cheaper than re-sending it, depending on the platform.
• Recheck after prompt changes. A small wording change can move the count more than expected.

#Frequently asked questions

#Bottom line

Token counting is capacity planning: how much of the window is used, what is left for the answer, and what the request will roughly cost. Treat the number as a close estimate, not an invoice, and always count the whole request rather than just the document. Start with the LLM token counter, then trim the prompt with the system prompt optimizer if the window is tight.