Mobile Opt-in Forms: Designing for Thumb-Friendly Conversion
Keyboard types, tap target sizes, and the autofill behaviour that decides whether a form takes four seconds or forty.
On this page
The short version
- Three attributes — input type, autocomplete and inputmode — turn fifteen seconds of thumb typing into two taps. They matter more than anything visual.
- The keyboard covers roughly half the screen when it opens. A form positioned without accounting for that puts its own button out of reach.
- Tap targets need real physical size and real separation, or the submit button and whatever sits beneath it become a coin toss.
Most signups happen on a phone, and a phone is a hostile place to type an email address. The difference between a form that converts on mobile and one that does not is mostly about how little typing it demands, not how it looks.
The good news is that the largest wins are three HTML attributes, and they are free.
The three attributes
| Attribute | Value | What it does |
|---|---|---|
| type | Shows a keyboard with @ and . visible | |
| autocomplete | Offers the saved address in one tap | |
| inputmode | Reinforces the keyboard on clients that need it | |
| autocapitalize | off | Stops the first letter being capitalised |
| autocorrect | off | Stops the address being 'corrected' |
| spellcheck | false | Removes the red underline on a valid address |
Autocomplete is the largest single win on this table. A visitor whose browser fills the field has done no typing at all, and the address is guaranteed to be one they actually use.
The keyboard takes half the screen
When the field is focused, the on-screen keyboard occupies roughly the bottom half of the viewport. A form whose submit button sits just below the field will find that button underneath the keyboard, and the visitor has to dismiss the keyboard to reach it.
Some browsers scroll the focused element into view and some do not, and the ones that do choose their own position. The reliable arrangement is a compact form — headline, one field, button — that fits entirely in the upper half of the screen, so the whole thing remains visible with the keyboard open.
This is one of the strongest arguments for a single field on mobile. Two fields and a button plus a privacy line will not fit above the keyboard on a small phone.
The three numbers
44px
Minimum tap target, each dimension
Roughly an adult thumb pad
16px
Minimum input font size
Below this, iOS zooms the page on focus
~50%
Screen taken by the keyboard
Design the form to fit above it
The 16px rule that is not about readability
An input with a font size below 16px causes iOS Safari to zoom the page when the field is focused. The zoom is not undone when the field blurs, so the visitor is left on a zoomed page that no longer fits, usually mid-form.
It is a layout bug that presents as a typography choice. Setting inputs to 16px prevents it entirely, and the font size is fine anyway.
Separation, not just size
A 44px button directly above a 44px link is two adequate targets that still produce mis-taps, because a thumb landing near the boundary is ambiguous. Targets need space between them as well as size.
The specific case worth designing around is a submit button sitting immediately above a dismiss or close control. A mis-tap there does not just fail — it closes the thing the person was trying to complete.
Mobile form check
- type, autocomplete and inputmode all set to email
- autocapitalize, autocorrect and spellcheck disabled on the field
- Input font size is at least 16px
- One field, so the whole form fits above the keyboard
- Button is at least 44px tall with padding, not a bare link
- Clear separation between the button and any dismiss control
- Completed end to end on a real phone, not a simulator
Frequently asked questions
Should I autofocus the field on mobile?
Only on a dedicated page whose sole purpose is the form. Autofocus inside a scrolling page brings up the keyboard and jumps the view, which reads as the page malfunctioning.
What about sign-in-with-provider buttons?
They remove typing entirely and cost you the address the person actually reads, since provider accounts are often not their preferred inbox. Worth testing rather than assuming either way.
Does a sticky bar work better than an inline form on mobile?
Often, because it is always reachable and does not cover the content. Keep it to a button that expands rather than a permanent field, which takes up the same space and looks like a search box.