Retool Number Format: Using Comma as Decimal Separator

If you're building a Retool app for European users, you've almost certainly hit this wall: the default numeric input field does not accept a comma as a decimal separator. For users in the Netherlands, Germany, Belgium, Poland, and most of Europe, Retool number format defaults to the US convention (dot as decimal, comma as thousands separator), which causes real data-entry errors. A user on a Dutch OS pressing the decimal key on their numpad gets a comma — which Retool silently drops, turning €10,50 into €1050. That's not a UX annoyance; that's a financial bug.

Why Retool Doesn't Support Locale-Based Number Formatting by Default

Retool's numeric input and table column types are built around a single global format. There is currently no organisation-level or app-level setting to switch the decimal separator to a comma and the thousands separator to a dot. Retool has acknowledged this as a long-term roadmap item — but as of now, it requires resources to implement properly across all components, so it hasn't shipped yet. The browser's preferred language does influence formatting in some cases (Retool confirmed this in a tweet from 2021), but relying on each end-user's browser language is not a scalable or reliable solution for a production internal tool.

The Quickest Workaround: toLocaleString() for Display

For read-only display of numbers — inside a table cell, a text component, or a stat card — the fastest fix is JavaScript's built-in toLocaleString() method. You can use it directly in a Retool expression:

• In a table column set to string type, use: {{ item.price.toLocaleString("nl-NL") }}
• For Belgian French formatting: {{ item.price.toLocaleString("fr-BE") }}
• For German formatting: {{ item.price.toLocaleString("de-DE") }}

This renders 1050.5 as 1.050,5 exactly as European users expect. The catch — and it's a significant one — is that the value becomes a string. The moment it's a string, your table's built-in sort and numeric range filters break. You can no longer filter "between 100 and 500" reliably. This workaround is fine for reporting screens; it falls apart the moment users need to interact with the data.

Handling Numeric Input Fields with Comma Decimal Entry

For input fields where users need to type numbers — especially using a numpad — you need a different approach. The recommended pattern is to swap the Number Input component for a standard Text Input and handle the conversion yourself. Here's a step-by-step approach:

• Step 1: Use a Text Input component instead of a Number Input. This allows the field to accept both dots and commas without silently stripping characters.
• Step 2: In a transformer or the query that consumes the value, normalise the input: {{ parseFloat(textInput1.value.replace(",", ".")) }}
• Step 3: Add client-side validation with a regex to give users immediate feedback if the format is wrong: {{ /^\d+(,\d+)?$/.test(textInput1.value) }} — use this to drive a showError state on the input.
• Step 4: Store and compute with the parsed float, never the raw string. Only convert back to a localised string at the display layer using toLocaleString().

Yes, this is more work than it should be. But it gives you full control over both entry and display while keeping the underlying data as a real numeric type that sorts, filters, and calculates correctly.

Working with Locale-Formatted Numbers in Retool Tables

Tables are the hardest case. If you format a column as a string for display purposes, you lose sorting. If you leave it as a number, European users see dots instead of commas. The least-bad solution right now is a two-column approach:

• Keep the original numeric column in the table's data source but hide it using the column visibility toggle.
• Add a computed/custom column that displays the localised string version: {{ self.toLocaleString("de-DE") }}.
• Set the hidden numeric column as the sort key by using a custom onSort handler or by structuring your query to sort server-side.

This is a workaround, not a solution — but it keeps sort behaviour intact while showing the correct locale format to users.

The Real Fix: Vote for Locale Support in Retool

The root of this problem is the absence of an organisation-level locale setting in Retool. What teams actually need is the ability to set a default locale (e.g., nl-NL, de-DE) at the app or org level so that all number inputs, table columns, and display components automatically respect the correct decimal and thousands separators — including numpad input. Retool is tracking this request. If this is a blocker for your team, upvoting the feature request in the Retool community forum is the most direct way to move it up the roadmap.

Summary

Until Retool ships native locale-aware number formatting, here's the practical breakdown: use toLocaleString() for display-only contexts, use a Text Input with a replace("," , ".") normalisation for data entry, and keep raw numeric values in your data layer for sorting and filtering. It's extra plumbing, but it protects your users from silent data errors — which, in a financial or operations tool, is non-negotiable.