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.
Thanks! This is great info and a thorough description. Awesome knowledge.
(I didn’t see this above, but maybe I missed it) – Looking at the demo you provided, I’ll add that I noticed these also have an effect on the keyboards’ long-press shortcuts, like when you hold down
.– whether it displays a list of
.netetc., or if doing so brings up a shortcut of grammatical symbols, etc.
Thanks again. Great article and reference.
Is there a trick to tell the keyboard to use only lower case? For example on both url and email inputs above, if I just start entering the information, the inputs look like the following:
It’s not a big deal to hit shift, but I’d like to remove that step for the user.
Hi Jared. Yes- you can use
Just a heads up, the email field doesn’t show the decimal sign, it’s just the dot. In other languages where the decimal sign is the comma “,” the dot still appear as it’s used to fill in emails ;)
Thanks for pointing that out Rafael! We’ve amended the article.
Do you know how to enable “though it is still available via a flag” ?
You only need to enable inputmode via a flag on Firefox for Android. To do this enter
about:configin the URL bar to see the advanced settings there. Search form ‘inputmode’ then toggle on the
dom.forms.inputmodeoption and then Firefox for Android will support inputmode just like Chrome for Android does!
Something interesting to note in your example for
input[inputmode="numeric"]: Dutch PIN codes are actually alphanumeric (I live in
7543AC) so perhaps we should stick to plain
Same goes for some ZIP codes in the EU. You just need to know your market and adjust.
Hi Anand Chowdhary – thanks for the feedback. When I mentioned that
inputmode="numeric"is good for PINs, I meant PIN as in Personal Identification Number – like a 4 digit passcode to login to a system for example. I didn’t mean it was suitable for post codes.
Nice article man. Thanks for sharing
what about date and time?
Hi Steve – There are input types for date and time (you can test ’em at: https://inputtypes.com/ ), but there aren’t custom keyboards for those via inputmode.
Safari in iOS 13 Supports „none“. The keyboard disappears
ah yes, just noticed this on my iPad with iPadOS 13 Beta. thanks for sharing!
Your example has the inputmode=verbatim but it is not mentioned in the definitions above. What is it for?
ah well spotted. inputmode=verbatim was previously in the spec but has since been removed – so I removed it from https://inputmodes.com/ now too.
iOS 15 Browser does not always show the dot in
decimalinputs but it depends on the user interface locale!
lang="en-us"on the input or root element does not provide us a dot on German phones :-(
And yes, no negative numbers as we have no minus key…