Everything You Ever Wanted to Know About inputmode
The inputmode global attribute provides a hint to browsers for devices with onscreen keyboards to help them decide which keyboard to display when a user has selected any input or textarea element.
Unlike changing the type of the form, inputmode doesn’t change the way the browser interprets the input — it instructs the browser which keyboard to display. The inputmode attribute has a long history but has only very recently been adopted by the two major mobile browsers: Safari for iOS and Chrome for Android. Before that, it was implemented in Firefox for Android way back in 2012, and then subsequently removed several months later (though it is still available via a flag). Almost six years later, Chrome for Android implemented the feature — and with the recent release of iOS 12.2, Safari now supports it too.
This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.
Desktop
Mobile / Tablet
Based on my tests, inputmode is indeed supported in Opera Mini and Opera Mobile, which contradicts the Caniuse data above. I’ve reached out to see if we can sync up our findings. But before we go deep into the ins and outs of the attribute, consider that the WHATWG living standard provides inputmode documentation while the W3C 5.2 spec no longer lists it in its contents, which suggests they consider it obsolete. Given that WHATWG has documented it and browsers have worked toward supporting it, we’re going to go assume WHATWG specifications are the standard. inputmode accepts a number of values. Let’s go through them, one by one.
We’re starting here because it’s very possible we don’t want any type of keyboard on an input. Using inputmode=none will not show a keyboard at all on Chrome for Android. iOS 12.2 will still show its default alphanumeric keyboard, so specifying none could be sort of a reset for iOS in that regard. Regardless, none is intended for content that renders its own keyboard control.
This one is probably the one of the more common inputmode values out in the wild because it’s ideal for inputs that require numbers but no letters — things like PIN entry, zip codes, credit card numbers, etc. Using the numeric value with an input of type=»text» may actually make more sense than setting the input to type=»number» alone because, unlike a , inputmode=»numeric» can be used with maxlength , minlength and pattern attributes, making it more versatile for different use cases. I’ve often seen sites using type=tel on an input to display a numeric keyboard, and that checks out as a workaround, but isn’t semantically correct. If that bums you out, remember that inputmode supports patterns, we can add pattern=»\d*» to the input for the same effect. That said, only use this if you are certain the input should only allow numeric input because Android (unlike iOS) doesn’t allow the user to change to the keyboard to use letters, which might inadvertently prevent users from submitting valid data.
Entering a telephone number using a standard alphanumeric keyboard can be a pain. For one, each number on a telephone keyboard (except 1 and 0) represents three letters (e.g. 2 represents A, B and C) which are displayed with the number. The alphanumeric keyboard does not reference those letters, so decoding a telephone number containing letters (e.g. 1-800-COLLECT ) takes more mental power. Using inputmode set to tel will produce a standard-looking telephone keyboard, including keys for digits 0 to 9, the pound ( # ) character, and the asterisk ( * ) character. Plus, we get those alphabetic mnemonic labels (e.g. ABC).
An inputmode set to the decimal value results in a subtle change in iOS where the keyboard appears to be exactly the same as the tel value, but replaces the +*# key with a simple decimal ( . ). On the flip side, this has no effect on Android, which will simply use the numeric keyboard.
I’m sure you (and at least someone you know) has filled out a form that asks for an email address, only to make you swap keyboards to access the @ character. It’s not life-threatening or anything, but certainly not a great user experience either. That’s where the email value comes in. It brings the @ character into the fray, as well as the dot ( . ) character. This could also be a useful keyboard to show users who need to enter a Twitter username, given that @ is a core Twitter character for identifying users. However, the email address suggestions that iOS display above the keyboard may cause confusion. Another use case could be if you have your own email validation script and don’t want to use the browsers built-in email validation.
The url value provides a handy shortcut for users to append TLDs (e.g. .com or .co.uk ) with a single key, as well keys typically used in web addresses, like the dot ( . ) and forward slash ( / ) characters. The exact TLD displayed on the keyboard is tied to the user’s locale. This could also be a useful keyboard to show users if your input accepts domain names (e.g. css-tricks.com ) as well as full URIs (e.g. https://css-tricks.com ). Use type=»url» instead if your input requires validating the input.
This displays a blue Go key on iOS and a green Enter key on Android, both in place of where Return . As you may have guessed by the value’s name, search is useful for search forms, providing that submission key to make a query. If you’d like to show Search instead of Enter on iOS and a magnifying glass icon on Android in place of the green arrow, use type=search instead.
Other things you oughta know
- Chromium-based browsers on Android — such as Microsoft Edge, Brave and Opera — share the same inputmode behavior as Chrome.
- I haven’t included details of keyboards on iPad for the sake of brevity. It’s mostly the same as iPhone but includes more keys. Same is true for Android tablets, save for third-party keyboards, which might be another topic worth covering.
- The original proposed spec had the values kana and katakana for Japanese input but they were never implemented by any browser and have since been removed from the spec.
- latin-name was also one of the values of the original spec and has since been removed. Interestingly, if it’s used now on Safari for iOS, it will display the user’s name as a suggestion above the keyboard.
Oh, you want to see how all of these input modes work for yourself? Here’s a demo you can use on a device with a touchscreen keyboard to see the differences.
inputmode
The inputmode global attribute is an enumerated attribute that hints at the type of data that might be entered by the user while editing the element or its contents. This allows a browser to display an appropriate virtual keyboard.
It’s important to understand that the inputmode attribute doesn’t cause any validity requirements to be enforced on input. To require that input conforms to a particular data type, choose an appropriate element type . For specific guidance on choosing types, see the Values section.
Values
The attribute can have any of the following values:
No virtual keyboard. For when the page implements its own keyboard input control.
Standard input keyboard for the user’s current locale.
Fractional numeric input keyboard containing the digits and decimal separator for the user’s locale (typically . or , ). Devices may or may not show a minus key ( — ).
Numeric input keyboard, but only requires the digits 0–9. Devices may or may not show a minus key.
A telephone keypad input, including the digits 0–9, the asterisk ( * ), and the pound ( # ) key. Inputs that *require* a telephone number should typically use instead.
A virtual keyboard optimized for search input. For instance, the return/submit key may be labeled «Search», along with possible other optimizations. Inputs that require a search query should typically use instead.
A virtual keyboard optimized for entering email addresses. Typically includes the @ character as well as other optimizations. Inputs that require email addresses should typically use instead.
A keypad optimized for entering URLs. This may have the / key more prominent, for example. Enhanced features could include history access and so on. Inputs that require a URL should typically use instead.
Specifications
Browser compatibility
BCD tables only load in the browser
See also
Found a content problem with this page?
This page was last modified on Jun 20, 2023 by MDN contributors.
Your blueprint for a better internet.