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.
<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.
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
Chrome | Firefox | IE | Edge | Safari |
---|---|---|---|---|
66 | 95 | No | 79 | No |
Mobile / Tablet
Android Chrome | Android Firefox | Android | iOS Safari |
---|---|---|---|
117 | 117 | 117 | 12.2-12.5 |
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.
None
<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.
Numeric
<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 maxlength
, minlength
and pattern
attributes, making it more versatile for different use cases.

numeric
value on Chrome Android (left) and iOS 12.2 (right)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.
Tel
<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.

tel
value on Chrome Android (left) and iOS 12.2 (right)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).
Decimal
<input type="text" inputmode="decimal" />

decimal
value on Chrome Android (left) and iOS 12.2 (right)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.
<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 email
value comes in. It brings the @ character into the fray, as well as the dot (.) character.

email
value on Chrome Android (left) and iOS 12.2 (right)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.
URL
<input type="text" inputmode="url" />

url
value on Chrome Android (left) and iOS 12.2 (right)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.
Search
<input type="text" inputmode="search" />

search
value on Chrome Android (left) and iOS 12.2 (right)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 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
andkatakana
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.

latin-name
value displays my name as an auto-fill suggestionDemo
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.com
,.net
etc., 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:
[email protected]
http://example.com
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
autocapitalize=off
for that.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.
Great post!
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:config
in the URL bar to see the advanced settings there. Search form ‘inputmode’ then toggle on thedom.forms.inputmode
option 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 in7543AC
) so perhaps we should stick to plaininput[type="text"]
for those.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
decimal
inputs but it depends on the user interface locale!Even setting
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…