Back to compare picker

Date input vs Input mask vs Text input vs Select

Prefer date input when users already know the exact date or can look it up and the task needs day, month, and year as separate understandable parts.

Decision dimensions

Dimension Date inputInput maskText inputSelect
UI or UX UI + UX - Grouped manual exact-date entryUI + UX - Fixed-format text entry controlUI + UX - Single-line freeform data-entry controlUI + UX - Single-choice dropdown control
UI guidance Render day, month, and year as separate text inputs inside one fieldset with a legend that asks the full date question and a hint containing a valid example date.Show a persistent label, visible example or hint, fixed grouping, literal separators, and field-adjacent error text so users understand which characters are typed and which are supplied by the mask.Render a persistent label, appropriately sized single-line input, optional hint, visible focus state, and nearby error text that is programmatically associated with the field.Render a persistent label, hint text, native closed value, finite option list, selected option, and validation state.
UX guidance Use date input when users already know the exact date or can look it up without needing calendar context.Use an input mask to help users enter data that has a stable character structure, especially when grouping matches the physical document, card, container code, or serial key users are copying from.Use text input for short freeform answers that users can type or paste and that cannot be accurately represented as a fixed option choice.Help users choose one value from a moderate known list without showing every option permanently.
Good UI A passport issued question uses a fieldset legend, hint example 27 3 2007, separate Day, Month, and Year labels, numeric input mode, and a group error that names the missing year.A container number field shows the example ABCD 123456 7, groups pasted characters into that shape, and displays the raw value ABCD1234567 before submit.A reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty.Persistent label, hint text, visible selected value, readable options, and clear required validation state.
Bad UI A single date field shows DD/MM/YYYY inside the input and removes the only instruction when users start typing.A phone field hard-codes a domestic mask and rejects valid international numbers.The only instruction is placeholder text that disappears when the user starts typing.Placeholder as the only label.
Good UX A user types 7 Jan 1984, sees month normalized to 01, submits, and reviews canonical value 1984-01-07.A user pastes abcd1234567, sees ABCD 123456 7, reviews the canonical value, and fixes one middle digit without retyping the whole code.A user types or pastes a short reference, submits it, and the interface confirms the stored value without changing their wording.Users can open, scan, choose one value, and review the selected value after close.
Bad UX A user pastes a known birth date into a masked field and the interface discards separators and jumps focus unpredictably.A user pastes a valid value with spaces and the mask discards characters because it only supports one-character-at-a-time typing.Validation fires on the first focus event and blocks typing before the user has had a chance to answer.Hiding two obvious critical choices in a dropdown.
Best fit Users already know the exact date or can look it up easily.The value has a stable character pattern and users benefit from live grouping.The answer is short and user-authored.The user chooses one option from a moderate known list.
Avoid when Users are unlikely to know the exact date.Valid values have many lengths, regions, scripts, or exception formats.The answer is a paragraph, comment, address block, or explanation requiring multiple lines.The option set is short and comparison matters.
Required state Empty untouched grouped date fields with legend, hint, and visible part labels.Empty untouched state with label and visible format example.Empty untouched state with persistent label and optional hint.Closed state with empty option or current selected value.
Accessibility burden Group the three inputs in a fieldset with a legend that states the full date question.Keep a real visible label and do not use the mask pattern or placeholder as a substitute for the field name.Associate every text input with a visible label or equivalent accessible name that matches the visible question.Prefer native semantics or implement equivalent name, role, state, and keyboard behavior.
Common misuse Using one freeform field with disappearing format instructions.Using a mask because a format exists even though many valid values do not fit it.Using placeholder text as the only label or instruction.Custom select with no keyboard support or hidden selected state.

Date input

UI or UX
UI + UX - Grouped manual exact-date entry
UI guidance
Render day, month, and year as separate text inputs inside one fieldset with a legend that asks the full date question and a hint containing a valid example date.
UX guidance
Use date input when users already know the exact date or can look it up without needing calendar context.
Good UI
A passport issued question uses a fieldset legend, hint example 27 3 2007, separate Day, Month, and Year labels, numeric input mode, and a group error that names the missing year.
Bad UI
A single date field shows DD/MM/YYYY inside the input and removes the only instruction when users start typing.
Good UX
A user types 7 Jan 1984, sees month normalized to 01, submits, and reviews canonical value 1984-01-07.
Bad UX
A user pastes a known birth date into a masked field and the interface discards separators and jumps focus unpredictably.
Best fit
Users already know the exact date or can look it up easily.
Avoid when
Users are unlikely to know the exact date.
Required state
Empty untouched grouped date fields with legend, hint, and visible part labels.
Accessibility burden
Group the three inputs in a fieldset with a legend that states the full date question.
Common misuse
Using one freeform field with disappearing format instructions.

Input mask

UI or UX
UI + UX - Fixed-format text entry control
UI guidance
Show a persistent label, visible example or hint, fixed grouping, literal separators, and field-adjacent error text so users understand which characters are typed and which are supplied by the mask.
UX guidance
Use an input mask to help users enter data that has a stable character structure, especially when grouping matches the physical document, card, container code, or serial key users are copying from.
Good UI
A container number field shows the example ABCD 123456 7, groups pasted characters into that shape, and displays the raw value ABCD1234567 before submit.
Bad UI
A phone field hard-codes a domestic mask and rejects valid international numbers.
Good UX
A user pastes abcd1234567, sees ABCD 123456 7, reviews the canonical value, and fixes one middle digit without retyping the whole code.
Bad UX
A user pastes a valid value with spaces and the mask discards characters because it only supports one-character-at-a-time typing.
Best fit
The value has a stable character pattern and users benefit from live grouping.
Avoid when
Valid values have many lengths, regions, scripts, or exception formats.
Required state
Empty untouched state with label and visible format example.
Accessibility burden
Keep a real visible label and do not use the mask pattern or placeholder as a substitute for the field name.
Common misuse
Using a mask because a format exists even though many valid values do not fit it.

Text input

UI or UX
UI + UX - Single-line freeform data-entry control
UI guidance
Render a persistent label, appropriately sized single-line input, optional hint, visible focus state, and nearby error text that is programmatically associated with the field.
UX guidance
Use text input for short freeform answers that users can type or paste and that cannot be accurately represented as a fixed option choice.
Good UI
A reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty.
Bad UI
The only instruction is placeholder text that disappears when the user starts typing.
Good UX
A user types or pastes a short reference, submits it, and the interface confirms the stored value without changing their wording.
Bad UX
Validation fires on the first focus event and blocks typing before the user has had a chance to answer.
Best fit
The answer is short and user-authored.
Avoid when
The answer is a paragraph, comment, address block, or explanation requiring multiple lines.
Required state
Empty untouched state with persistent label and optional hint.
Accessibility burden
Associate every text input with a visible label or equivalent accessible name that matches the visible question.
Common misuse
Using placeholder text as the only label or instruction.

Select

UI or UX
UI + UX - Single-choice dropdown control
UI guidance
Render a persistent label, hint text, native closed value, finite option list, selected option, and validation state.
UX guidance
Help users choose one value from a moderate known list without showing every option permanently.
Good UI
Persistent label, hint text, visible selected value, readable options, and clear required validation state.
Bad UI
Placeholder as the only label.
Good UX
Users can open, scan, choose one value, and review the selected value after close.
Bad UX
Hiding two obvious critical choices in a dropdown.
Best fit
The user chooses one option from a moderate known list.
Avoid when
The option set is short and comparison matters.
Required state
Closed state with empty option or current selected value.
Accessibility burden
Prefer native semantics or implement equivalent name, role, state, and keyboard behavior.
Common misuse
Custom select with no keyboard support or hidden selected state.
Decision rules
  • Prefer date input when users already know the exact date or can look it up and the task needs day, month, and year as separate understandable parts.
  • Prefer a date picker outside this comparison when users are scheduling, comparing availability, or choosing from calendar context rather than recalling a known date.
  • Prefer input mask only when the value is a fixed-format identifier; do not mask dates if it prevents month-name entry, partial recovery, or clear part-specific errors.
  • Prefer text input when the answer is a short non-date value or when the product accepts fuzzy wording such as a season, month name only, or approximate period.
  • Prefer select for a small finite set such as month names, school years, or appointment slots, not for arbitrary birth dates or historical dates.
  • Ask a single date question in a fieldset with a legend, separate labels for day, month, and year, and an example date that matches the requested date.
  • Do not automatically move focus between day, month, and year because it conflicts with normal keyboard editing, paste, screen readers, and correction.
  • Accept common month-name forms when users type them in the month field, then normalize to a canonical numeric month for storage.
  • Show group-level errors that name the missing, impossible, or out-of-range part while preserving every typed part for correction.
  • Use birthday autocomplete attributes only when asking for the user's own date of birth, not for every date field.
Inspect live examples
Failure modes
  • A date mask rejects a user who types Jan for the month even though the intended component should tolerate month names.
  • A calendar picker is forced on users who already know their date of birth and just need fast keyboard entry.
  • Three inputs are shown without a fieldset or legend, so assistive technology users hear isolated Day, Month, Year labels without the actual question.
  • The form auto-tabs after two digits and makes it hard to correct a day or paste a copied date.
  • The product reports only Invalid date without naming whether day, month, year, range, or impossible-date validation failed.
  • A select control makes users scroll through hundreds of years instead of typing a known date.