Why Portuguese uses more tokens than English (and what to do about it)

By LW Forge — maintainer of LLM Scout · Updated September 7, 2026

Write the same sentence in English and Portuguese, feed both into the same model, and the Portuguese version comes out as more tokens — not because it says more, but because of how the tokenizer that turns text into tokens was built. If you budget in reais using an English rule of thumb, you will underestimate your bill every time, and the gap is large enough to matter at any real volume.

Why one language costs more than another

A tokenizer doesn't understand language; it's a compression table built by counting which chunks of text appear most often in a training corpus, then giving the most frequent chunks their own token. Every major LLM tokenizer — OpenAI's o200k, the ones behind Claude and Gemini — is trained on a corpus that is disproportionately English. The result is mechanical, not linguistic: common English words and word-pieces get single tokens, while the same concepts in Portuguese, built from less-frequent character sequences and heavier use of accents (ç, ã, õ), get split into more pieces.

This isn't a fringe finding. An academic study on tokenizer fairness across languages measured Portuguese needing roughly 50% more tokens than English for equivalent content on GPT-4-family tokenizers, and a separate analysis of LLaMA 3.2 found English compressing to 4.9 characters per token against 3.6-3.8 for Portuguese, French and Spanish — a "fertility" (tokens per word) that climbs from 1.24 in English to 1.60-1.71 in Romance languages. Our own tokens explained piece quoted a more conservative 10-25% for casual prose on the newer o200k tokenizer that GPT-5.6 uses, which is trained on a somewhat more multilingual mix than its predecessors. Both numbers are correct — they're measuring different tokenizer generations and different kinds of text. The honest range for Portuguese today is 15% to 50% more tokens than English, and where you land in that range depends on the model, the formality of the text, and how many accented words and long verb conjugations it contains.

Why the range is so wide

Three variables move a specific piece of Portuguese text up or down that range:

Tokenizer generation. Older, English-heavy vocabularies (GPT-3.5/4-era, most open-weight base models) show the widest gap. Newer multilingual-aware tokenizers, including the ones behind GPT-5.6 and Claude's current models, have shrunk it by training on more non-English text — but haven't closed it.
Formality and vocabulary. Formal Portuguese with longer words and more verb conjugations (subjunctive forms, for instance) tokenizes worse than casual, short-sentence Portuguese. Technical and business writing sits at the expensive end.
Content type. Portuguese with a lot of numbers, code, or English loanwords (common in tech writing) tokenizes closer to English, because those tokens are shared across languages.

That variance is exactly why a fixed multiplier is only a planning tool. Paste your actual Portuguese prompts — not a sample paragraph — into the token calculator and compare the count against the same text in English. It takes thirty seconds and removes the guesswork the studies above can't.

What this costs at real volume

Take a support chatbot answering in Portuguese for a Brazilian audience: 10,000 conversations a month, 1,500 input and 200 output tokens per exchange in English terms. Apply a 30% tokenization tax — the middle of the credible range — to both sides, and the monthly bill on GPT-5.6 Terra at August 2026 prices ($2.00 / $12.00 per million) moves from about $432 to roughly $562. On Claude Sonnet 5 ($3.00 / $15.00), it moves from $720 to about $936. Neither jump changes which model is cheapest — the ranking between providers is unaffected by language, since the tax applies to both — but it does mean a budget built from an English estimate and simply "translated" will run 20-40% over.

The fix isn't switching languages; it's estimating in the language you'll actually use. Run your real Portuguese prompt volume through the OpenAI or Claude calculator rather than adjusting an English number by hand.

Three ways to shrink the tax

Write shorter system prompts, twice. A verbose Portuguese system prompt pays the tokenization tax on every single call. Trim it in Portuguese specifically — remove redundant formal constructions, prefer shorter verb forms — rather than just translating an English prompt that was already optimized for English's cheaper tokenization.

Push structured output to English keys. If your application returns JSON with a mix of Portuguese content and structural keys, keep the keys ("resposta", "confiança") in English or abbreviated form. The keys repeat on every call; the content doesn't need to.

Cache the parts that don't change. A Portuguese system prompt and few-shot examples are exactly the kind of stable prefix that benefits from prompt caching, which bills cached reads at roughly 10% of the input rate regardless of language. See prompt caching savings for when the caching math works in your favor.

The number that actually matters

Don't try to memorize a single multiplier — memorize the habit of testing. Tokenizers keep changing generation to generation, the gap has been shrinking for two years and will likely keep shrinking, and the exact number depends on what you write, not just which language you write it in. The token calculator gives you today's real count for your real prompt; everything in this article is context for reading that number correctly, not a replacement for it.