Input Types for Mobile Keyboards

Pick input types and inputmode so mobile keyboards match the data — email, tel, numeric OTP, dates, and the desktop side effects.

beginner3 min readUpdated Aug 4, 2026

html
input-types
mobile

On phones, the on-screen keyboard is half the form UX. Correct type and inputmode values surface @, .com, number pads, and OTP-friendly layouts without custom keyboard code.

Docs: MDN <input>, inputmode, input types.

High-value types

<label for="email">Email</label>
<input id="email" name="email" type="email" autocomplete="email" />

<label for="tel">Phone</label>
<input id="tel" name="tel" type="tel" autocomplete="tel" />

<label for="url">Website</label>
<input id="url" name="url" type="url" autocomplete="url" />

<label for="qty">Quantity</label>
<input id="qty" name="qty" type="number" min="1" inputmode="numeric" />

type	Mobile keyboard / UI
`email`	`@` and `.` emphasis; basic format validation
`tel`	Phone pad (varies)
`url`	`/` `.com` helpers on some OS
`number`	Numeric-ish; has steppers/validation quirks
`search`	Sometimes clear button; semantic search
`password`	Obscured; manager integration
`date` / `time` / `datetime-local`	Native pickers (inconsistent UI)

inputmode for finer control

inputmode hints the keyboard without changing the value’s validation the way some types do.

<!-- OTP -->
<input
  name="otp"
  inputmode="numeric"
  pattern="[0-9]*"
  autocomplete="one-time-code"
  maxlength="6"
/>

<!-- Decimals without type=number spinner issues -->
<input name="amount" inputmode="decimal" />

<!-- Email-like without type validation edge cases -->
<input name="contact" inputmode="email" />

Common values: text, tel, url, email, numeric, decimal, search.

type=number caveats

<input type="number" name="age" />

Issues:

Scroll-wheel accidental changes on desktop
Locale decimal separators
Empty vs invalid states
Leading zeros stripped (bad for some codes)

For OTPs, zip codes, and credit-card segments, prefer inputmode="numeric" + pattern on type="text" (plus autocomplete tokens).

Dates

<label for="dob">Date of birth</label>
<input id="dob" name="dob" type="date" autocomplete="bday" />

Native date inputs improve mobile entry but are awkward to style and vary by browser. For complex ranges, many products still use custom pickers — then keep a hidden or synced native input for progressive enhancement when possible.

Desktop still matters

Types that change validation (email, url) affect desktop form submission too. Don’t pick a type only for the keyboard if the validation rules are wrong for your backend.

Interview out-loud

“I choose type for semantics and validation — email, tel, url, date — and use inputmode when I need a keyboard hint without number-input quirks. OTPs use numeric inputmode, maxlength, and autocomplete=one-time-code. I avoid type=number for non-quantity codes.”

Footguns

Zip codes with type="number" dropping leading zeros.
Forcing custom keyboards via JS hacks.
Missing labels — keyboard type doesn’t replace accessible names.
Assuming all Android/iOS keyboards honor every inputmode.
Styling native date inputs to death until they break.

Payment-ish fields (structure only)

<label for="cc">Card number</label>
<input
  id="cc"
  name="cc"
  inputmode="numeric"
  autocomplete="cc-number"
  maxlength="19"
  spellcheck="false"
/>

Do not log or store PAN data without PCI scope. Prefer hosted fields from a payment provider when possible. Keyboard hints still improve entry on mobile even when the iframe is third-party — host pages control their own non-sensitive fields.

Search fields

<form role="search" action="/search">
  <label for="q">Search docs</label>
  <input id="q" name="q" type="search" enterkeyhint="search" autocomplete="off" />
  <button type="submit">Search</button>
</form>

type="search" can offer a clear control on some platforms. enterkeyhint customizes the mobile enter key label. Keep a real submit button for accessibility and progressive enhancement.