The Number Formatter Guide: Separators, Decimals, Currency, and Percentages That Don't Break

A raw number like 1234567.89 is unreadable. Drop it into a report, a dashboard label, or a finance email and the reader's eye stops to count digits. Worse, the moment you format it for one audience, you risk garbling it for another, because the same comma that means "thousands" in New York means "decimal point" in Berlin. This guide walks through the practical rules of formatting numbers for reports and spreadsheets, and where the quiet failures hide.

The worked example everyone needs

Start with the canonical case: turn 1234567.89 into something a person can read at a glance.

In US English, that becomes 1,234,567.89 — a comma every three digits from the right, a period for the decimal. The grouping is what does the work. Without it you get 1234567.89 and have to mentally chunk the digits; with it, "one point two million" jumps out immediately.

Now the trap. Take that exact same value and write it the German way and you get 1.234.567,89 — dots for grouping, a comma for the decimal. The French convention writes it 1 234 567,89, using a thin no-break space as the group separator. Three correct answers for one number. If you hard-code the US version and ship it to a German spreadsheet, the reader sees 1,234,567.89 and reads 1,234 as "one point two three four" followed by garbage. The number didn't change. The convention did.

You can run all three side by side in the Number Formatter: type the value once, switch the grouping locale, and copy the row you actually need.

Thousands separators differ by locale — and not just by symbol

The symbol swap (comma versus period versus space) is only half the story. The grouping pattern itself changes too.

Most Western locales group in threes: 1,234,567. Indian English does not. It groups the first three digits, then in twos: 12,34,567 — that's the lakh/crore system, and a finance report aimed at Mumbai readers that uses Western grouping looks subtly wrong to every person who reads it. Chinese, Japanese, and Korean compact notation breaks at every ten thousand rather than every thousand, which is why 万 (10,000) and 亿 (100,000,000) exist as units with no English equivalent. "1.2M" in English is "120万" in Chinese — not a translation, a re-grouping.

The reason a tool beats a regex here is that the browser already ships a correct table for all of this through Intl.NumberFormat. It knows German uses dots, French uses a narrow space, and Indian English uses lakhs. Hand-rolled string padding works until you hit the first locale you didn't test, and then it ships a wrong number to a real customer.

Decimal places: pick a count and commit

The second formatting decision is how many digits after the decimal point. This is less about correctness and more about discipline.

For a financial table, fix the decimals at two and never waver — 19.50, not 19.5, and 1,000.00, not 1000. A column where some cells show two decimals and others show none reads as sloppy, and in a spreadsheet it breaks visual alignment of the decimal points. For a metrics dashboard, you usually want the opposite: round hard, show 1.2M instead of 1,234,567, and let the reader drill in if they care.

There's a subtler reason to pin the decimal count. JavaScript numbers are IEEE-754 doubles, so 0.1 + 0.2 famously yields 0.30000000000000004. Formatting whatever value you're handed will faithfully show that artifact. Fixing the displayed decimals to a sane count hides it. For money you must keep exact, the real fix is upstream — store and compute in integer minor units (cents) and only format at the very last step. Format is a display concern, never a storage one.

Currency and percentages have their own rules

Currency formatting layers a symbol, a decimal convention, and a locale-specific position all at once. $1,234.50 puts the dollar sign in front. The euro often trails: 1.234,56 €. Japanese yen carries no decimal places at all, so ¥1,000 is correct and ¥1,000.00 is wrong — yen has no minor unit in everyday use. Get this from a proper formatter rather than concatenating a symbol onto a number, or you'll ship ¥1000.00 to a Tokyo invoice and look careless.

Percentages have a smaller but sharper gotcha: the value you store and the value you show differ by a factor of 100. A stored 0.25 displays as 25%. If you format 25 as a percent you get 2500%. When you parse a pasted 25% back into a machine number, it should come back as 0.25. Keep the storage form and the display form straight in your head, and decide once where the ÷100 happens. For the math behind those conversions — markup, discount, change over time — the Percentage Calculator handles the arithmetic so the formatter only has to handle the display.

How I caught this in my own reports

I learned the comma-versus-period lesson the embarrassing way. I was preparing a weekly summary for a cross-region team and pasted a revenue figure — 1.234.567,89, copied straight out of a German colleague's spreadsheet — into my own sheet, which was set to US locale. My sheet read the dots as thousands grouping and the trailing ,89 as a stray text fragment, and silently turned a 1.2-million-euro number into something nonsensical. Nobody flagged it until the figures didn't reconcile two days later. Now my habit is fixed: before I trust any number pasted from another region, I run it through a reverse parser to get the plain machine value first — 1.234.567,89 back to 1234567.89 — and only then format it for my audience. The thirty seconds it costs has saved me from re-sending a corrected report more than once.

A quick checklist for reports and spreadsheets

Know your reader's locale before you format, not after. The same digits need different grouping for US, German, French, and Indian audiences.
Pin decimal places per column. Two for money, zero for counts, consistent within a column so the decimals line up.
Never store a formatted string. Keep raw numbers (or integer cents) and format only at the display edge.
Reverse-parse anything pasted from elsewhere. A foreign 1,5 means one-and-a-half, not fifteen; confirm the source locale instead of trusting a single comma group.
Match compact units to the language. "K/M/B" for English readers, "万/亿" for Chinese ones — they group at different powers and are not interchangeable.

Format is the last thing a number passes through before a human reads it. Treat it as a presentation step, keep the raw value pristine underneath, and let a locale-aware tool handle the conventions you'd otherwise get wrong one locale at a time.

Made by Toolora · Updated 2026-06-13