Interface strings

Compound nouns and long technical words; the classic worst case for tight buttons.

Estimate

Type one or more interface strings above.

What this does and cannot do

Each locale carries a low and a high multiplier taken from common localization planning ranges — German x1.20–x1.35, Japanese x0.50–x0.70, and so on. The range is the point: actual length depends on the translator, terminology and tone, so the estimate is shown as a band, never as a single number.

This tool estimates length; it does not translate, and it has no dictionary of your product's terms. Contracting targets (CJK) and expanding ones (German, Finnish) are treated the same way — arithmetic on character counts.

Characters are counted as code points, so an emoji counts once. Lines are compared to the same English source, which is what this estimator assumes; if your source is not English, the multipliers no longer apply. Everything runs in the browser.

The text expansion estimator projects how long English interface strings become in seventeen target locales, using published planning ranges and showing every per-string estimate together with the arithmetic behind it.

What is Text Expansion Estimator?

Translating an interface changes how much room the strings take, and this text expansion estimator turns that into planning numbers. Paste one English string per line, choose a target locale, and every line is projected as a range: source characters multiplied by the locale's low and high multipliers, with placeholders excluded from the expanding base and added back untouched. The range is the point — actual text expansion depends on the translator, the terminology and the tone, so the tool reports a band and shows the multipliers it used.

The multipliers come from common localization planning guidance and are listed for every locale on the page. German runs x1.20 to x1.35 because compound nouns can double the length of a short label; Finnish runs x1.25 to x1.40 because agglutination builds meaning into endings; French and Spanish sit around x1.15 to x1.25; the Nordic languages are usually close to English at x1.05 to x1.15. Contracting targets are included too: Japanese is x0.50 to x0.70, Chinese x0.40 to x0.60 and Korean x0.50 to x0.70, because character-based writing packs more meaning into fewer characters.

Placeholders are handled the way a localization runtime handles them: they are not translated, so {name}, {{count}}, %s and ${value} are measured separately, removed from the base that expands, and added back at their original length. Rounding is per line, and the totals are sums of the lines you can see, so the headline number can be recomputed from the table. Counting is by code point, which means an emoji counts once rather than twice.

An optional character budget turns the estimate into a design check. Enter the width of a button, a tab or a table column, and any line whose high estimate exceeds it is flagged as a possible overflow; the totals report how many lines are at risk. The estimator also flags short strings — fewer than ten translatable characters — because short labels expand proportionally more than averages suggest: Edit can become Bearbeiten, a 200% jump that no planning range predicts. Those rows are marked rather than silently trusted.

What the tool cannot do is just as explicit. It does not translate anything, it has no glossary of your product's terms, and it cannot see your layout: it estimates character length, not pixel width, so proportional fonts, icon spacing and line wrapping are beyond it. The multipliers assume an English source; if your source is German or Japanese, the ranges no longer apply as written. And a range is not a measurement of your actual translator's output — it is the number to design with before that output exists.

In a release cycle the estimator fits before design freeze and before a string freeze. Run the strings that live in fixed-width places first — buttons, tabs, table headers, tooltips — and compare them against their budget. Then run the longer copy to see whether cards and dialogs need more room. Keep the report with the design ticket: it records the range you planned against and every line that was close to overflowing, which is exactly what a reviewer needs when the German build arrives longer than the mockup.

How to use Text Expansion Estimator

  1. Paste one English interface string per line — buttons, tabs and labels first.
  2. Choose the target locale; the select shows each locale's planning range.
  3. Optionally enter a character budget to flag the strings likely to overflow it.
  4. Read the per-string table: estimate range, percentage change, and any overflow or short-string flags.
  5. Copy or download the report and keep it with the design ticket for the translation review.

When to use Text Expansion Estimator vs related tools

Use this estimator when the question is how much room translated text needs, and reach for different tools when the question is what the text contains. The Character Count Tool measures the English source exactly, including spaces, and the Language Detector identifies the language of a translated sample when you are checking a delivery.

When the concern is byte length rather than character length, the Character Encoding Converter shows what the same string costs once encoded.

Privacy & Security

This tool runs entirely in your browser — no data ever leaves your device. There is no server round-trip, no upload, no logging, and no account required. Your input is processed locally using client-side JavaScript and is never stored, transmitted, or accessible to anyone else. When you close the tab, everything disappears.

Frequently asked questions about Text Expansion Estimator