Token counter

Token counter

What the token counter does

Paste text in and this app gives you a quick read on how many tokens it would take up, the unit models use for both context window limits and, on paid APIs, cost. It works by splitting the text at whitespace and around punctuation, which tracks reasonably close to how a real tokenizer behaves without matching any specific one exactly.

It's local. Everything runs in your browser, so nothing you paste is uploaded, and there's no limit on length or how often you come back.

The point isn't precision to the token, it's a fast sanity check before you commit a long piece of text to something that has a hard limit or a per-token price.

Workflow

How to estimate tokens in three steps

Nothing to configure. The count updates as fast as you paste.

Step 1

Paste your text into the input box.

Step 2

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

Step 3

Trim and recheck if you're close to a limit you care about.

The basics

What a token actually is

A token is the chunk of text a model processes internally, and it isn't the same as a word or a character. A short common word is usually one token; a longer or less common one can split into two or three. Punctuation frequently counts as its own token, separate from the word beside it.

That's why token count and word count diverge, sometimes by a lot, and why a tool built specifically around tokens is more useful than a plain word counter when you're actually working against a model's limit or its pricing.

Straight answer

Is this the exact number a specific model would count?

No, and nothing running purely in a browser can honestly claim that. Every model family, OpenAI's, Anthropic's, Google's, whoever's, uses its own tokenizer built from its own vocabulary. The same sentence can come out to a meaningfully different count on two different models.

This gives a fast, reasonable estimate based on where text typically splits: at word boundaries and around punctuation. Treat it as a planning number, close enough to budget against a limit, not the exact figure any specific provider would bill you for.

What throws it off

What makes an estimate diverge from a real tokenizer

Code is the biggest source of divergence: symbols, indentation and unusual identifiers tokenise very differently across models, and a word-and-punctuation estimate doesn't capture that precisely. Non-English text, especially languages that don't separate words with spaces, can tokenise at a noticeably different rate than English, sometimes using more tokens for the same content, sometimes fewer.

Repeated or unusual punctuation, dense technical vocabulary and long runs of numbers or symbols all push a real tokenizer's count away from a simple estimate, in either direction.

Why it matters

Why context windows and per-token pricing matter here

A model's context window is the total tokens it can consider at once: your prompt, any earlier conversation, and its reply, all counted together. Go over it and older content gets dropped or the request fails outright, which is why a quick check before pasting something long is worth the few seconds it takes.

For paid usage, the token count drives the bill directly, since most providers charge per token both ways. A rough estimate before committing to a long input heads off a surprise on either the limit or the invoice.

Who it's for

Who uses a token counter, and when

Developers building against a paid API use it to sanity-check a prompt template before it runs against real traffic, catching an oversized input before it becomes an oversized bill. Anyone feeding a model a long document, a full conversation history or a large code file uses it to see roughly how close they are to the ceiling.

Writers preparing a long passage for a chat interface use it to gauge whether it'll fit in one paste or needs splitting first.