Why your token count doesn't match your bill

A token is not a word, and it is not a character. It is whatever the model's tokenizer decided a common chunk of text looks like, learned from the data it was trained on. That single fact explains most of the surprise on a first invoice.

The same text, different counts#

Paste an English paragraph into this calculator and you will see the counts sit fairly close together across models. Paste a JSON payload, a stack trace, or a paragraph of German, and they diverge. Tokenizers are tuned on a corpus, and text that looks unlike that corpus fragments into more pieces.

Three things reliably inflate a count:

• Rare words and identifiers. getUserPreferences is one word to you and often four or five tokens to a model.
• Non-English text. Languages underrepresented in training data can take two to three times as many tokens for the same meaning.
• Whitespace and punctuation-heavy formatting. Deeply indented JSON spends real tokens on structure rather than content.

Input and output are not priced alike#

Output tokens typically cost three to five times what input tokens cost. A prompt that is cheap to send can be expensive to answer, which means trimming your prompt is only half the lever — constraining the response length is often the bigger win. Toggle between Input and Output pricing in the comparison table to see the gap on your own text.

What the calculator does and doesn't know#

GPT counts here are exact: they run in your browser using the real tokenizer, so nothing you paste leaves the page. Counts for other providers may be estimates unless an API key is configured, and estimates assume roughly average English prose — precisely the assumption that breaks on code and non-English text.

Treat the numbers as a close guide for planning, and verify against your provider's own usage reporting before you commit to a budget.