The input[type=number] element introduced in HTML5 has a well-documented locality problem: browsers are permitted — and in several cases required — to display numbers using locale-specific formatting, while the value attribute and form submission always use a dot as the decimal separator. This split between the displayed representation and the programmatic value is the source of a class of bugs that appear only for users whose system locale uses a comma as the decimal separator. This page covers the display-versus-value split, the specific decimal separator divergence between comma and period locales, validation behaviour under different locale conditions, and how browser implementations compare. Sections cover each of these topics plus practical code patterns. This page is part of the web development section and connects to the open web topic hub.

The attribute-versus-display split​

This design reflects a broader HTML philosophy: the programmatic interface remains locale-neutral so that JavaScript and server-side code can reliably parse values without locale-specific handling, while the rendered control can be user-friendly for the local convention. The philosophy is sound but the execution is complicated by inconsistent browser implementation and by the validation model that intersects with locale handling in non-obvious ways.

Decimal separator differences across locales​

The fundamental tension is between two large groups of countries with incompatible conventions. Most English-speaking countries, along with China, Japan, and a number of others, use a dot as the decimal separator: 3.14. A large part of continental Europe, most of South America, and several other regions use a comma: 3,14. The HTML number input sits directly in the middle of this divide.

The Firefox behaviour is arguably more correct from a user experience standpoint — showing the number in the user's local format and accepting their natural input — but it creates a specific problem: web applications that validate the field value client-side using JavaScript's parseFloat() without locale awareness will correctly parse input.value (which is always dot-delimited) but may fail to handle the case where the browser is currently displaying a comma-formatted value that has not yet been committed to the programmatic value.

Validation behaviour​

The validation model for input[type=number] interacts with locale handling in two places: the browser's built-in constraint validation and any JavaScript validation layer applied by the application.

The browser's built-in constraint validation — triggered by form.checkValidity() or on form submission — applies the locale-appropriate acceptance criteria. A browser configured for a comma-locale that accepts comma input will mark that input as valid through its constraint system. A browser that only accepts dot-decimal input will mark comma input as invalid. This means that input.checkValidity() alone is not a reliable cross-locale validation signal.

Cross-browser consistency​

Practical code patterns​

The safest approach is to avoid relying on locale-specific display behaviour for programmatic processing and to validate through the numeric value property.

const input = document.querySelector('input[type="number"]');

// Safe: always returns a float or NaN, regardless of locale display
const numericValue = input.valueAsNumber;

if (isNaN(numericValue)) {
  // Input is empty or contains non-numeric content
  showError('Please enter a valid number.');
} else if (numericValue < input.min || numericValue > input.max) {
  showError(`Value must be between ${input.min} and ${input.max}.`);
} else {
  // Valid — use numericValue for further processing
  processValue(numericValue);
}

When displaying a number back to the user outside the input element, use the Intl.NumberFormat API rather than string interpolation — this correctly formats the number for the user's locale without tying that formatting to the input element's value transmission.

// Format for display — respects user locale
const formatter = new Intl.NumberFormat(undefined, {
  minimumFractionDigits: 2,
  maximumFractionDigits: 2
});

const displayString = formatter.format(numericValue);
// "1.50" in en-US, "1,50" in de-DE — both correct for that locale

For cases where input[type=number] is genuinely problematic — highly localised user bases, complex number formatting requirements, or applications that need full control over validation messaging — input[type=text] combined with explicit inputmode="decimal" and a JavaScript parsing layer is a viable alternative. It sacrifices the built-in spinner control and constraint validation but provides complete control over accepted input format.

The broader implication​

The input[type=number] locale situation is a good example of how HTML's "localise the display, normalise the value" design intention can produce real interoperability problems when browser implementations are inconsistent. The specification's position is reasonable; the implementation gap is the problem. Until all major browsers converge on identical locale handling behaviour, the only safe approach is to treat the display as informational and always process values through the numeric DOM property.