Use a date picker when users choose a single date with calendar context, availability, or day-of-week meaning; use date input for known exact dates, select for short fixed date choices, and text input for fuzzy date wording.
Use a date picker when users choose a single date with calendar context, availability, or day-of-week meaning; use date input for known exact dates, select for short fixed date choices, and text input for fuzzy date wording.
Practice the judgment: Imagine this situation: A birthday flow opens on the current month and forces dozens of year changes instead of accepting typed date parts. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Date picker | Date input | Select | Text input |
|---|---|---|---|---|
| UI or UX | UI + UX - Single-date text field with attached calendar menu | UI + UX - Grouped manual exact-date entry | UI + UX - Single-choice dropdown control | UI + UX - Single-line freeform data-entry control |
| UI guidance | Render a labelled date text field with a persistent format hint and a calendar button that opens a month grid aligned to the field. | 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. | Render a persistent label, hint text, native closed value, finite option list, selected option, and validation state. | 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 a date picker when choosing a date requires calendar context such as weekday, nearby availability, booking windows, deadlines, or recent/future scheduling. | Preserve every typed part, tolerate common month names, normalize to a canonical date only after validation, and explain exactly which part is missing, impossible, or out of range. | Help the person reach a clear task outcome. | Let users edit normally, validate after interaction or attempted submit, preserve their typed value after errors, and explain exactly how to fix invalid or missing text. |
| Good UI | An appointment booking field shows Appointment date, hint mm/dd/yyyy, a calendar button, July 2026 grid, disabled weekends, today marker, and selected July 14 date. | 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. | Persistent label, hint text, visible selected value, readable options, and clear required validation state. | A reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty. |
| Bad UI | A grid of unlabeled numbers uses pale grey for unavailable dates but still lets users click them before showing a late error. | A single date field shows DD/MM/YYYY inside the input and removes the only instruction when users start typing. | Placeholder as the only label. | The only instruction is placeholder text that disappears when the user starts typing. |
| Good UX | A user opens the calendar, sees weekends unavailable, moves to August, chooses Tuesday 11 August 2026, and reviews stored value 2026-08-11. | A user types 7 Jan 1984, sees month normalized to 01, submits, and reviews canonical value 1984-01-07. | Users can open, scan, choose one value, and review the selected value after close. | A user leaves the required field blank, sees an error only after submit, returns to the same field, and their later typed value clears the error. |
| Bad UX | A user selects a disabled Saturday because it was only dimmed, then loses their previous month when the error appears. | A user pastes a known birth date into a masked field and the interface discards separators and jumps focus unpredictably. | Hiding two obvious critical choices in a dropdown. | Validation fires on the first focus event and blocks typing before the user has had a chance to answer. |
| Best fit | Users are scheduling, booking, planning, or selecting a recent or future date. | Users already know the exact date or can look it up easily. | The user chooses one option from a moderate known list. | The answer is short and user-authored. |
| Avoid when | The date is far in the past, such as a birthday or historic document date. | Users are unlikely to know the exact date. | The option set is short and comparison matters. | The answer is a paragraph, comment, address block, or explanation requiring multiple lines. |
| Required state | Closed labelled text field with visible date-format hint and calendar button. | Empty untouched grouped date fields with legend, hint, and visible part labels. | Closed state with empty option or current selected value. | Empty untouched state with persistent label and optional hint. |
| Accessibility burden | Give the calendar button an accessible name and state that distinguishes opening from closing the menu. | Group the three inputs in a fieldset with a legend that states the full date question. | Prefer native semantics or implement equivalent name, role, state, and keyboard behavior. | Associate every text input with a visible label or equivalent accessible name that matches the visible question. |
| Common misuse | Using a calendar picker for a date of birth or other remembered historic date. | Using one freeform field with disappearing format instructions. | Using select to hide two or three obvious choices that should be compared. | Using placeholder text as the only label or instruction. |