A phone opens a number pad when a user taps a form field. That looks like a restriction to numbers, but the keyboard is only an input aid. Pasted text, hardware keyboards and direct requests can still supply values the application does not expect.
The MDN reference for inputmode describes it as a hint to the browser about the kind of input expected. It does not impose validity requirements. The distinction matters when a convenient keyboard is mistaken for a data-validation rule.
Choose the field’s meaning first
A numeric-looking identifier is not always a quantity. A membership code may need leading zeroes preserved, while an amount may require a decimal separator. Decide what the value represents before choosing an input type and keyboard hint.
For an identifier consisting of digits, a text field with an appropriate numeric keyboard hint may be useful. For a genuine number, a number input may fit. The complete choice also depends on the permitted format, locale and accessibility requirements.
Test more than tapping keys
- Paste a value containing spaces or letters.
- Enter a value with a leading zero where the business rule permits it.
- Try the decimal and negative forms that the field is supposed to support.
- Submit an empty value and check whether the explanation matches the requirement.
Keep the label visible and explain format constraints before the error where possible. Avoid silently changing an identifier into a different one while trying to tidy it.
Client-side checks can guide the user, but the server must validate submitted data too. MDN’s input documentation explains that browser validation does not guarantee valid data reaches the server.
In a review, ask two separate questions: “Is this easy to enter on the device?” and “Will the application handle unexpected input correctly?” Inputmode helps with the first. It cannot answer the second on its own.