Token Counter

Paste or type text and the counts update as you go: characters, words, and the exact number of tokens under two OpenAI encodings. o200k_base is what GPT-4o, GPT-4.1 and the o-series reasoning models use; cl100k_base is the older encoding behind GPT-4 and GPT-3.5. The same text often differs by a few percent between the two, which is why both are shown. The tokenizer is the real byte-pair encoder, not an approximation, so the numbers match what the API bills.

Claude and Gemini do not ship a tokenizer that can run in a browser, so the figure for them is an estimate and is labelled as such. It uses a simple rule of thumb: roughly 3.5 characters per token for Latin-script text and about 1.5 characters per token for Korean, Japanese and Chinese. Expect it to be off by 20 percent or more on code, unusual formatting or mixed languages; use it for rough budgeting and treat the usage field in the API response as the only exact figure.

Token counts matter because they decide whether a prompt fits the context window, how much a request costs, and how much room is left for the answer. The coloured chips under the counts show how the tokenizer splits the first two hundred tokens. A common English word is usually one token, while a Korean or Japanese character is often two or three, which is why the same document costs more in those languages. Looking at the chips is the quickest way to see what is inflating a prompt: long URLs, base64 blobs and repeated whitespace stand out immediately.

Everything runs locally. The tokenizer dictionaries are downloaded once when you first type, a few megabytes each, and after that the text never leaves the page. Pasting a confidential prompt or an internal document is safe. Inputs over a million characters are refused because encoding them would freeze the tab; split those before counting.