input type=”number”: When to Use It and When to Avoid It
In the past, we only had input type=“text”; now we have a wide variety of input types, including “number”. What sounds smart in the first place to use this specific type comes with several caveats, especially when your application serves an international audience.
The main issue with input type=“number” in Europe is that the standard number format uses a period (.), which you’ll see in .value and form submissions. However, many users naturally enter decimals with a comma (,), such as “3,14159.” The ability to type commas and whether they are accepted depends on the locale and browser, leading to potential validation errors and an inconsistent experience for international users.
You see my point; why does it not make sense to use this particular HTML control? It would require a lot of explanation on why to use a period instead of a comma. Especially, it would be error-prone too.
Input[number] for numbers
Generally, this type of input field has limited use.
The number input type should only be used for incremental numbers, especially when spinbutton incrementing and decrementing are helpful to the user experience. The number input type is not suitable for values that consist only of numbers but aren’t strictly speaking a number, such as postal codes in many countries or credit card numbers. – MDN
Using incremental steps can sometimes be useful for an e-commerce-heavy site to change the number of items you like to order, but in most cases, it comes with many caveats.
Sure, you could add the step attribute to the input field that will allow you to increment in “0.1” steps up and down the number, but what if the exact number that I have to enter is “3.14159”? It would be a lost cause, and users would have to rely on their keyboard again to enter the correct number.
Input type number allows you to enter only numbers, right?
The answer is both yes and no. While HTML’s “valid floating-point number” syntax uses a dot (.), which appears in .value and form submissions, the input users can type depends on their locale and browser. In locales that use commas for decimal points, some browsers accept inputs like 1,5 and convert them, while others reject these inputs or behave unpredictably. Therefore, relying solely on type=“number” for a consistent decimal user experience across different locales can be unreliable.
Depending on the browser, users might enter characters not valid as numbers, such as e, +, -, or emojis. These keystrokes may be accepted, but the field will still fail validation, so validation and clear error handling are necessary.
The field input will become invalid, of course, but you have to check the input manually anyway and convert the string value to an actual number.
Even for me, in Austria, this would be a correct number; the red border indicates that the input is invalid. The comma is not an allowed input.
What else to use instead
The input type ‘text’ is, by far, still the most versatile option for numbers. Over the years, more options have become available to help you and your users set the correct number.
pattern regex
One option is the attribute pattern that you can input into your text field.
<input type="text" pattern="[0-9]+([.,][0-9]+)?">
This will allow you to enter a number in the following forms:
- 3,14159
- 3.14159
Now you have a perfect candidate for internationalisation. If you like, go fancy with the following pattern.
<input type="text" pattern="^\d+([.,]\d+)?$">
This allows the input of the following numbers:
- 3
- 3,14159
- 3.14159
It still doesn’t prevent the user from adding emojis, but the value of the text field will become automatically invalid.
With the comma notation for us Austrians, you have to “normalize” the valid input a bit with the following two lines of code.
const normalized = inputValue.replace(',', '.');
const num = parseFloat(normalized);
Just replace the comma with a period, and you can parse the number as a float.
Input mode
To enter numbers, mobile devices have a dedicated number keypad. Normally, an input of type “text” shows the full keyboard. By adding the “inputmode” attribute to the input field and setting it to numeric or decimal, you can open up the correct keyboard automatically.
Numeric allows you to select digits from 0 to 9. Decimal shows a fractional numeric input keyboard with the digits and decimal separator for the user’s locale (typically the period (.) or the comma (,)).
This input mode is not only useful for traditional text fields, but there are even scenarios when an input of type number does not show the correct keyboard. If you take a closer look, it even shows the “invalid” comma instead of the required period on the keyboard.
Does the number field even make sense
By 2025, using input type=“number” for international decimal input remains risky. The HTML specification’s syntax for floating-point numbers uses a period (.) as the decimal separator. Still, actual browser behavior differs regarding whether users in comma-decimal locales can enter numbers like 1,5. Some browsers normalize it, others reject it—particularly Chromium. To ensure a more consistent and locale-sensitive user experience, it’s better to use type=“text” combined with inputmode=“decimal” and handle parsing and validation ourselves.
In some scenarios, it might be useful; in most cases, it is not, as I pointed out in this blog post. When I work with enterprise applications, I often deal with different number systems and user input that includes both commas and periods. In this international context, this type has more negative than positive effects.
The decimal delimiter is just one of the issues; sometimes the user enters thousand separators as well, which the language also needs to handle.
Despite the growing demand for localized input experiences, browser support for the input[type=“number”] element with locale-specific decimal separators remains inconsistent as of 2025. Firefox and Safari lead the way with broader support, correctly interpreting the page’s lang or user locale. In contrast, Chrome, Edge, and other Chromium-based browsers continue to lag, especially on Windows and Linux, where they only recognize the dot (.) regardless of language settings. Mobile support, particularly on Android, remains unpredictable. Until consistent handling is guaranteed across platforms, consider using input[type=”text”] with custom validation patterns to ensure a user-friendly and locale-aware number input experience.
Further interesting articles
- You probably don’t need input type=“number” – Brad Frost
- I Wanted To Type a Number – Zack Leatherman