How does validation „Number“ work? Problems with that in field „Data Input“ and wrong decimals

be_Berlin · August 28, 2026, 2:55pm

Situation:

I have a table that stores weight of inventory.

The field „weight“ in that table Inventory is set to have one decimal.

Weight can get bigger or smaller so that new numbers should be stored to document that changes.

I build an application that gives the user the chance to add a new weight or take away weight.

It works that way that there are to different Input Forms in the App. One Forms to add weight, the other to reduce weight.

In these two different Input Forms I have elements type “Data Input”.
They are labeled “weight to add” and the other (in the other Input Form) is labeled “weight to reduce”

I set the first Data Input (“Add weight”) with the property of “Validation” to Number.

By accident I forgot to do that for the other Data Input (“Reduce weight”). So now it has Validation “Any”

Question 1:

How exactly does the validation of “number” work?
I recognized that enter data like “3a2” immediately shows the error “The field must be a number.”. Enter data like “3,2” brings no error as well as “3.2” (regardless of the language system of my local system)
But also enter data like “3,2,.2,” does not show the error. Although it is obviously not a number.

I assume the field at the applications webpage just checks if there are only numbers and characters comma or full stop. Is that right? So the field not really checks if the entered data is a (float) number?

- Question 2 :

If I enter “3,2” in Data Input “Reduce weight” with it validation set to “any” the application excepts the data. It tries to write a new row but then it show this error in the upper right corner (Screenshot ).

And now for the real problem!!
If I enter “3,2” in Data Input “Add weight” with it validation set to “number” the application excepts the data – and writes a new row with “32” !! (yes, thirty two, not three point two).

So the weight is wrong by factor 10.

I assume that this might be connected with this problems:

Having Baserow accepting “3,2” as an input but writing a new row with 32 is a big problem as the user might not get aware of this problem.

I really look forward for your help and understanding of what is happening here.

Thanks.

jonadeline · August 31, 2026, 4:10pm

Hi @be_Berlin,

Thank you for the detailed report. You are absolutely right: entering 3,2 and having it stored as 32 is not expected behaviour.

The Number validation is intended to accept valid integer and decimal values. At the moment, however, the Data Input first normalises the value using the active locale. In an English locale, a comma is treated as a thousands separator and removed before validation. As a result, 3,2 becomes 32; similarly, 3,2,.2, can become 32.2, which explains why it passes validation.

With validation set to Any, the raw value 3,2 reaches the Number field unchanged and is rejected server-side, which explains the error toast.

This is a bug in the Application Builder input parsing and should not be relied on for comma-decimal input. Until it is fixed, please use one ungrouped decimal format matching the application’s active locale—for example, 3.2 in an English locale—and do not mix , and . or use thousands separators.

I’ve created an issue in our backlog where you can track the progress:

github.com/baserow/baserow

Application Builder Number Data Input silently converts 3,2 to 32

opened 04:02PM - 31 Aug 26 UTC

jonadeline

application 📱

### Describe the problem The Application Builder's **Data Input** element with …**Validation = Number** can silently change a decimal value when parsing localized input. In an English locale, entering `3,2` is accepted and submitted as `32` instead of being rejected or treated safely as a decimal value. Malformed input such as `3,2,.2,` can also pass validation and become `32.2`. This is a data-integrity issue: the user receives no validation error, while an incorrect inventory weight is stored. The parser appears to use the active locale rather than the thousand/decimal separator configured on the target Number field. It removes every occurrence of the locale's grouping separator before validating the result. Related Community report: https://community.baserow.io/t/how-does-validation-number-work-problems-with-that-in-field-data-input-and-wrong-decimals/12847 ### Technical notes The affected flow is in the Application Builder Data Input parser: - `InputTextElement` normalizes the value with `parseLocalizedNumber(value, this.$i18n.locale)`. - `parseLocalizedNumber` removes all grouping separators, then replaces the decimal separator. In an English locale this means: - `3,2` → `32` - `3,2,.2,` → `32.2` ### Steps to reproduce and actual result 1. Create a table with a Number field named `Weight`, configured with one decimal place. 2. Create an Application Builder form containing a Data Input element. 3. Set the Data Input's validation to **Number**. 4. Add a Create Row action that maps the Data Input value to `Weight`. 5. Use an English Application Builder locale. 6. Enter `3,2` and submit the form. **Actual result:** a row is created with `Weight = 32`. 7. Repeat with `3,2,.2,`. **Actual result:** the value can pass validation and be submitted as `32.2`. For comparison, when the Data Input validation is set to **Any**, `3,2` remains raw text and the Number field rejects it server-side. This produces an error toast rather than silently writing an incorrect value. ### Expected result Number validation must never silently change the numeric meaning of user input. - Invalid grouping such as `3,2` in an English locale should be rejected inline rather than converted to `32`. - Malformed input such as `3,2,.2,` must be rejected. - Valid localized decimal input should be parsed consistently and safely. - Ideally, the Data Input should have an explicit input-format setting ### Environment - Deployment Type: Baserow Cloud - Baserow Version: current Cloud version / develop source confirmed - Application Builder locale: English

Thank you again for documenting this so clearly.