Input is the single-line text field for forms, toolbars, and filter bars. It combines an optional label, the field itself, optional lead and tail icons, affixes for units and prefixes, helper text, and validation states. The mental model is "one fact per field"—with the right keyboard, the right format, and the right validation for that fact. Choose a semantic type (email, tel, password, number) rather than plain text when one exists; the right type gives mobile operators the correct keyboard without the app rewriting the OS.
Reset zoom to 100%
When to use
Collecting short free-form strings: names, codes, search queries, numeric identifiers where a number input isn't appropriate.
Filter bars and command surfaces where a single line of text drives a query.
Fields that benefit from lead icons (search, location) or tail icons (visibility toggle, clear).
Values with stable prefixes or suffixes (currency symbol, unit) displayed as affixes.
Choosing from a known set without free typing—use Select or Combobox.
Phone numbers with international formatting—use IntlPhoneNumberInput when that's the product standard.
Structured date or time entry—prefer dedicated date/time patterns.
Variants
Aspect
Purpose
Emphasis
type (email, tel, password, …)
Invokes the right software keyboard and validation hints
Match type to data; don't default to text when a semantic type exists
Lead / tail icons
Quick recognition and inline actions
Icons supplement labels; never the only error cue
Affixes
Static context (unit, protocol)
Keep short; no editable text inside affixes
Masking
Formats input as users type
Show expected shape in placeholder or helper; expose raw value to logic
With select
Combines scope and free text
Lead select when it sets format; tail select when it sets unit or scope
Content guidelines
Labels. Sentence case, specific enough that operators know what belongs in the field. Optional unit hints in the label reduce error ("Age (years)").
Helper text. Explains format or constraints before the user fails validation. On error, the message replaces the helper.
Placeholders. Examples or format sketches only; they never replace the label and disappear while typing.
Errors. Specific and corrective ("Use MM/DD/YYYY"), not only "Invalid".
Localize with formatMessage and test long translations inside the field width.
Behavior and states
Default, hover, focus. Visible focus ring; never remove focus styling.
Disabled vs. read-only. Disable when the field is irrelevant or blocked; use read-only when the value must be visible but not editable. Surface the reason in helper text when useful.
Validation. Prefer validating after reasonable completion rather than every keystroke, unless live validation is a known win for that field (password strength, address lookup).
Password. Offer reveal when appropriate. Never echo secrets in helper text or logs.
Autofill. Use meaningful autoComplete tokens for common fields; disable for sensitive one-off values.
Best practices
Do
Match field width to expected content so the shape sets an expectation. A 3-character code field should not look like a 60-character name field.
Use tail icons for reversible actions (clear, reveal) that don't steal focus confusingly.
Group related fields with consistent label and error placement so operators learn the rhythm.
Don't
Rely on placeholder alone for required fields—the placeholder vanishes while typing and takes the requirement with it.
Use an icon as the only error indicator. Pair with text.
Strip the user's paste or input without explanation when masking is on. Say so in helper text.
Accessibility
label associates with id; helper and error copy use aria-describedby; required and invalid state are exposed accessibly; focus into an invalid field reads the error. See Accessibility for the full contract.