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 type="text" inputmode="" /> <textarea inputmode="" />
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.
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.
Mobile / Tablet
|Android Chrome||Android Firefox||Android||iOS Safari|
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.
<input type="text" inputmode="none" />
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.
<input type="text" inputmode="numeric" />
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
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.
<input type="text" inputmode="tel" />
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.
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).
<input type="text" inputmode="decimal" />
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
<input type="text" inputmode="email" />
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
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.
<input type="text" inputmode="url" />
url value provides a handy shortcut for users to append TLDs (e.g.
.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.
type="url" instead if your input requires validating the input.
<input type="text" inputmode="search" />
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 showSearch instead of Enter on iOS and a magnifying glass icon on Android in place of the green arrow, use
Other things you oughta know
- Chromium-based browsers on Android — such as Microsoft Edge, Brave and Opera — share the same
inputmodebehavior 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
katakanafor Japanese input but they were never implemented by any browser and have since been removed from the spec.
latin-namewas 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.