Context budgets are quoted in tokens, but everything you actually paste is characters. The conversion between them is not one number, and the places it varies most are the ones people get caught by.
A character-ratio estimate is a useful budgeting tool if you know what it does. Here is what moves it.
Whitespace is nearly free
Tokenisers merge runs of whitespace, so counting raw characters badly overestimates indented text.
Take a small indented code block of 42 raw characters. Collapse each whitespace run to a single character and only 27 remain effective, which is what the estimate is actually built from. Under a code profile that block estimates at 9 tokens rather than the 14 you would get from the raw count.
This is why reformatting rarely costs what people expect. Adding indentation to a file changes the character count a lot and the token count very little.
The same text costs different amounts depending on what you call it
The ratio of characters to tokens is not constant across content types. Prose runs about 4 characters per token, mixed content about 3.5, and source code about 3.
A 186-character English paragraph estimates at 47 tokens under a prose profile, 54 under mixed, and 62 under code. Same text, same characters, a 32 percent spread purely from which profile you assume.
That matters when you are budgeting a prompt that contains both. Treating a code-heavy prompt as prose will understate it by roughly a third, and the failure mode is a request that gets truncated rather than one that errors cleanly.
Non-Latin scripts approach one token per character
This is the big one, and it is invisible if you only ever test in English.
A 57-character Greek sentence contains 47 non-ASCII characters. Because the estimate blends toward one token per character as non-ASCII density rises, it comes out at 38 tokens under a prose profile. An English sentence of the same length would be closer to 14.
So the same sentence, translated, can cost roughly two and a half times as much of your context budget. Anyone building a multilingual tool on an English-tested budget will find non-Latin users hitting limits that English users never see.
What this kind of estimate is not
It is a character-ratio heuristic, not a tokeniser. It does not implement byte-pair encoding and it is not calibrated against any particular model's vocabulary. The numbers above are for budgeting and for understanding which direction things move, not for predicting a bill.
If you need the exact count a specific model will charge you, you have to run that model's tokeniser. What a heuristic gives you is the shape of the problem: whitespace is cheap, code is denser than prose, and script matters more than either.
The practical version
Budget prose at roughly 4 characters per token and code at roughly 3. Do not bother optimising indentation. If your input is not in a Latin script, assume something close to one token per character and check before you rely on it.
For working through a specific context window against these ratios, ClaudHQ on whitespace free code dense does the arithmetic across profiles.