The Three-Attribute Rule for Mobile-Friendly Forms
Forms are rarely the highlight of a mobile experience, but they don't have to be a chore. The difference often comes down to three HTML attributes: type, inputmode, and autocomplete. Each one is useful on its own, but together they determine which keyboard appears, what suggestions the browser offers, and how smoothly a user can get through a form.
Start With the Right type
The most straightforward improvement is choosing the correct input type. Values like email, tel, and url are well-supported and immediately change the keyboard on Android and iOS when a field is focused. The effect is barely noticeable on desktop, but on mobile it's the difference between hunting for an @ symbol and having it one tap away.
One caveat: input type="email" and input type="url" come with built-in validation. Modern browsers will block form submission with an error tooltip if the value doesn't match the expected format. If you don't want that behavior, add the novalidate attribute to the containing form.
A Note on Date Inputs
Text-based inputs aren't the only option. The date type and its variants — time, datetime-local, and month — trigger native widgets on mobile instead of a keyboard. iOS shows a select-like interface; Android's date and time pickers are notably slick.
Still, most major apps and sites ship custom date pickers. The native iOS date selector is less intuitive than a calendar widget, and even Android's polished implementation is limited compared to custom components — there's no easy way to enter a date range, for example. The native types are worth testing if your custom picker underperforms on mobile, and you can keep desktop users on a custom widget while using native controls on touch devices:
::-webkit-calendar-picker-indicator {
display: none;
}
Also keep in mind that date types ignore the inputmode attribute entirely.
When inputmode Matters
The inputmode attribute lets you override the keyboard that an input's type would normally trigger. At first glance it seems redundant — why not just use the right type? The answer is the number input.
input type="number" has known accessibility issues and an awkward desktop UI, including tiny increment arrows in Chrome that are easy to trigger accidentally while scrolling. A better pattern for most numeric fields is a text input with an explicit keyboard mode:
<input type="number" /><input type="text" inputmode="decimal" />Why decimal instead of numeric? On Android the two values produce identical keyboards. On iOS, numeric shows numbers and punctuation, while decimal presents a focused numeric grid that closely resembles the tel keyboard — minus the phone-specific extras. That makes decimal the better default for general number entry.
numeric input (left) and decimal input (right)
numeric input (left) and decimal input (right)Autocomplete: Don't Rely on Browser Heuristics
Showing the right keyboard is helpful, but surfacing the right autocomplete suggestions is what really speeds up form completion. Browsers have heuristics for this, but they're not dependable. For instance, iOS Safari only showed autocomplete options for an input type="tel" when autocomplete="tel" was explicitly set.
Most developers know the common values for addresses and credit cards, but the spec lists over 50 options. It's worth a review — autocomplete="one-time-code", for example, can make phone verification flows dramatically smoother.
A Custom Autocomplete With datalist
For your own autocomplete suggestions, the datalist element is a lightweight option. On desktop Chrome and Safari it renders a basic autocomplete dropdown. On iOS it behaves differently to impressive effect: suggestions appear in a row directly above the keyboard, where system autocomplete normally lives, and users can toggle between text entry and a select-style picker.
Android takes a more conventional approach, showing a scrollable dropdown with the system's own typeahead suggestions above the keyboard. That offers immediate access to all options as soon as the field is focused, whereas iOS shows only the top few matches unless the user taps a down arrow to open the full picker.
You can experiment with these attributes and see how each input configuration behaves on mobile with a dedicated preview tool that lets you combine type, inputmode, and autocomplete values side by side.
The Takeaway
Mobile form optimization doesn't require a heavy investment. A few attributes, applied deliberately, can remove much of the friction from data entry on small screens. Correct type values select the right keyboard; inputmode fixes cases where type alone isn't sufficient; and explicit autocomplete values ensure the browser offers meaningful suggestions instead of guessing. Coding for mobile doesn't need to mean building separate flows — it can be as simple as labeling your inputs properly.
