Token counter

This tool estimates the number of tokens a piece of text would occupy, the unit models use to measure context window limits and, on paid APIs, cost. The estimate is derived by splitting text at whitespace and around punctuation, a method that approximates real tokenizer behaviour without replicating any specific model's vocabulary.

The calculation runs client-side, in JavaScript, in your own browser. There is no request sent to a server to log, queue or inspect, which is also why there is no run limit.

Nothing to configure. The estimate updates as text is entered.

Step 1

Paste the text into the input field.

Step 2

Read the estimated count, calculated instantly on your own device.

Step 3

Trim the input and recheck if approaching a limit that matters for your use case.

A token is the unit of text a model processes internally, distinct from a word or a character. A short, common word typically maps to a single token; a longer or less common word can split into several. Punctuation frequently constitutes its own token, separate from the adjacent word.

This distinction is why token counts and word counts diverge meaningfully, and why a tool purpose-built around token estimation serves a different function than a plain word counter when working against a model's context limit or its per-token pricing.

No client-side tool without a specific model's tokenizer bundled into it can produce that model's exact count, and this one does not claim to. Each model family, OpenAI's, Anthropic's, Google's and others, uses its own tokenizer built on its own vocabulary and its own training process. Identical text can yield meaningfully different counts across models.

This tool produces a reasonable estimate based on typical tokenisation boundaries: whitespace and punctuation. Treat the result as a planning figure sufficient for budgeting against a limit, not as the precise value a specific provider's API would bill or enforce.

Source code is the largest source of divergence: symbols, indentation and unconventional identifiers tokenise in ways that vary substantially across models, and a whitespace-and-punctuation estimate does not capture that precisely. Non-English text, particularly languages without space-delimited words, can tokenise at a materially different rate than English, sometimes requiring more tokens for equivalent content, sometimes fewer.

Dense technical vocabulary, unusual or repeated punctuation, and long runs of numerals or symbols all shift a real tokenizer's count away from this estimate, in either direction, depending on the specific model.

A model's context window is the maximum token count it can process in a single exchange, spanning the prompt, any preceding conversation, and the generated reply. Exceeding it causes earlier content to be dropped or the request to fail outright, making a rough estimate worthwhile before submitting a lengthy input.

For metered usage, token count also determines cost directly, since providers typically charge per token for both input and output. Estimating in advance of a long submission avoids an unanticipated outcome on either the limit or the invoice.

Developers building against a metered API use it to validate a prompt template before deploying it against live traffic, catching an oversized input before it becomes an oversized invoice. Anyone working near a model's context limit, a long document, an extended conversation history, a large code file, uses it to gauge proximity to that ceiling.

Researchers and writers preparing lengthy text for a chat interface use it to determine whether the passage fits in a single submission or requires splitting beforehand.