Input Field
The control a person types into — the most-used element in most products and the one where small decisions cost the most.
UI ComponentsAn input field is a component with a lot of states and a habit of shipping with three of them designed. It needs default, hover, focus, filled, disabled, read-only, error and — for anything asynchronous — loading. Focus deserves particular attention because the default browser outline is frequently removed for aesthetics and rarely replaced, which quietly makes the form unusable by keyboard.
The attributes matter more than the styling. `type` decides which keyboard appears on a phone and which native validation runs. `inputmode` refines it. `autocomplete` lets the browser and password manager fill known values, which is both faster and more accurate than typing. Labels must be real `<label>` elements tied to the input, not text positioned nearby, or assistive technology announces an unlabelled box.
Help text, not hope
If a field has a format requirement, state it before the user types — “8+ characters, one number” under the field, not as an error after they guess wrong. Constraints shown up front are guidance; the same words shown after submission are a failure message.
In practice
A fintech signup used `type="text"` for the phone field. On mobile it opened the alphabetic keyboard, and about 11% of submitted numbers were malformed. Changing the type and adding `autocomplete="tel"` — a two-attribute diff — removed nearly all of the malformed values.
Where teams get it wrong
- Removing the focus outline without replacing it, which breaks keyboard use silently.
- Placeholder as label. It disappears on typing and is invisible to many screen readers.
- Wrong `type` and no `autocomplete`, so mobile keyboards and password managers cannot help.
- Format rules revealed only as errors after submission.
- Disabled fields with no explanation of what would enable them.
Learn more
You may ask
Frequently Asked Questions
Should you use placeholder text instead of labels?
No. Placeholders vanish as soon as someone types, leaving no way to check what the field was asking, and many screen readers do not announce them. Use a visible label and keep the placeholder for an example value, if at all.
What input states need designing?
Default, hover, focus, filled, disabled, read-only and error, plus loading for anything that validates asynchronously. Focus and error are the two most often missing and the two that matter most.
Why does input type matter on mobile?
It selects the on-screen keyboard. `type="email"`, `type="tel"` and `inputmode="numeric"` give people the right keys immediately; a plain text field makes them hunt and produces more malformed entries.
Related terms
All terms- Form DesignDesigning the fields, sequence, validation and error handling of a form so people can finish it without stopping to think.
- Error StateWhat an interface shows when something failed — which system failed, whether the user's work survived, and what they can do next.
- ComboboxA text input joined to a filtered list — for choosing from more options than anyone should have to scroll through.
- CheckboxA control for independent on/off choices, any number of which can be selected at once — including none.
Defined by Mara Last reviewed .
Let's talk about your product.
Happy to look at what you're building and say where design would move the needle.
Contact Us