The estimate, and what it is not
A token is a sub-word piece of text. Models split writing with Byte Pair Encoding, an algorithm that merges frequent byte pairs into reusable units, so "encoding" can become "encod" and "ing". English averages about four bytes per token, which is where the shortcut comes from.
No quick estimator runs a real tokenizer. Characters divided by four is arithmetic, not encoding. It has no vocabulary, so it cannot know that a rare word splits into five pieces while a common one stays whole. Treat the number as a planning figure. It answers "will this fit", and it will not settle an API bill.
Exact counts come from the provider. OpenAI publishes its encodings, cl100k_base for GPT-4 and o200k_base for GPT-4o and the o-series, as an installable library. Anthropic publishes nothing, so the only exact source for Claude is the API's count_tokens endpoint.
The count sits under the text you copied, next to characters, words and lines, on every copy. Which means the prompt never has to travel anywhere to be measured, and no browser tab stays open for it.
Cleanup usually moves the number more than rewording does. Stripping invisible characters and runs of blank lines out of pasted model output cuts real tokens, and both happen in the same panel as the count.
Where four characters per token breaks
Code and JSON. Braces, indentation and punctuation tokenise densely, and English prose runs about 0.75 words per token while code drops toward 0.5. One JavaScript snippet measured 140 tokens on cl100k_base and 149 on o200k_base, so even two encodings from the same vendor disagree.
Other languages. One Spanish passage cost 30% more tokens under o200k_base and 56% more under cl100k_base than its English baseline. Chinese, Japanese and Cyrillic pack denser still. Long runs of digits do the same thing.
Different models, different answers. Each family ships its own tokenizer and vocabulary, and the same text can differ by 25% to 50% between them. If you are budgeting across two providers, count twice.
What I use
For one prompt, a web page is fine. Try it free in your browser, with the same characters-divided-by-four estimate and nothing uploaded.
My reason for building it into the app is smaller than accuracy. Checking a long prompt meant pasting it into somebody else's website, and I did not want to keep doing that with client work or unreleased copy. Klipto shows the estimate in the paste preview on every copy, offline, beside characters, words and lines. It is the same estimate, in a place where the text never leaves the Mac.