LLM Token Counter - Count GPT & Claude Tokens

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

Frequently asked questions

What is a token?

A token is the sub-word unit language models actually read and are priced by. Common short words are usually one token; longer or rarer words split into several.

Why do the counts differ between models?

Each model family uses its own tokenizer with its own learned vocabulary, so the same text produces a different token count depending on the encoding.

Is the Claude token count exact?

No - it's a labeled character-based estimate, since Anthropic doesn't publish a public Claude tokenizer.

Does my text get uploaded anywhere?

No. Tokenization runs entirely in your browser; nothing you paste is sent to a server.