LLM Token Counter - Count GPT & Claude Tokens

How to use this tool

1. Choose an input mode. Pick "Paste text" to tokenize what you type, or "Estimate from file size" to get a rough estimate from a file size and unit without pasting anything.
2. Compare token counts. See exact o200k_base and cl100k_base counts side by side with the labeled Claude and Gemini estimates.
3. Pick a model preset or enter your own price. Select a frontier model preset to auto-fill its input/output price per 1M tokens, or choose "Custom" to enter your own, and see the estimated cost for this text.

What tokens are and why they matter

Large language models don't read text one character at a time - they read tokens, which are common sub-word chunks learned from huge amounts of training text. A short common word like "the" is usually one token; a rarer or longer word like "tokenizer" often splits into several ("token" + "izer"). This matters because every API call to a hosted model is priced and limited by token count, not character or word count, so a prompt that looks short in characters can still be expensive or run over a context window if it's dense with rare words, code, or non-English text.

As a rough rule of thumb, English prose averages around 4 characters per token, but that ratio swings widely: source code, JSON, and other structured text tend to use more tokens per character because of frequent punctuation and short identifiers, while very repetitive text can compress into fewer tokens than the rule of thumb suggests. That variability is exactly why an exact tokenizer, not a character-count estimate, is the only reliable way to know your real token count before sending a prompt.

Why the counts differ between models

This tool counts tokens using the same open-source tokenizer library (gpt-tokenizer) that implements OpenAI's actual encodings, so the o200k_base and cl100k_base counts shown above are exact, not estimated. o200k_base is used by newer OpenAI models (GPT-4o, GPT-4.1, and the o1/o3 reasoning models); cl100k_base is used by GPT-3.5-turbo and GPT-4. The two encodings use different sub-word vocabularies, so the same input text can produce a noticeably different token count between them - o200k_base's larger vocabulary generally tokenizes English and code slightly more efficiently than cl100k_base.

Anthropic does not publish a public tokenizer for Claude models, so the Claude row is clearly labeled as an estimate: characters divided by 3.5, rounded up. That heuristic tracks real Claude token counts reasonably closely for typical English prose, but it will drift for code, tables, or other languages - treat it as a ballpark, not a number to budget a hard context-window limit against.

Worked example: estimating prompt cost

Say you're building a summarization feature that sends a 2,000-character system prompt plus a 6,000-character article to a model on every request. Pasting that combined 8,000 characters into the box above might show roughly 1,900 cl100k_base tokens. At a hypothetical price of $3 per million input tokens, that single request costs about $0.0057 - trivial alone, but at 10,000 requests a day it's roughly $57/day, which is the kind of number worth knowing before you ship. Enter your model's actual per-token price in the cost box to see this math for your own prompts.

Don't have the text handy, or working with a large file you don't want to paste? Switch to the "Estimate from file size" mode and enter a size and unit instead for a rough token estimate. The cost section also includes a dropdown of current frontier model presets across OpenAI, Anthropic, and Google that auto-fill input/output pricing per 1M tokens (or pick "Custom" to enter your own), plus an optional requests-per-day field to project daily and monthly spend, and CSV/PDF export of the full cost breakdown.

Reducing token usage