ui patterns
Date picker
When should I use a calendar date picker instead of a text field?
A date picker lets you choose a date from a calendar rather than typing it into a text box. Its job is to remove ambiguity and error: it shows valid days, settles the format question for you, and makes "03/04" impossible to misread - because you pick the day rather than describe it.
Also known as: date picker, calendar picker, datepicker
Prefer to watch?
Watch the recap 0:49
The demo
Choose a date. Try typing it, then pick it from the calendar - and notice which one lets you get it wrong.
What this demo shows (text version)
Entering a date is shown two ways. In "type it", a free-text field accepts whatever you write - so "03/04" is ambiguous (March the 4th, or April the 3rd?), and nothing stops you entering a day that doesn't exist or a date in the past.
In "calendar", you pick a day from a month grid. Only real, in-range days can be chosen, and there's no format to get wrong - the constraint prevents the errors the text field invited. The trade-off: for a date you already know, especially a distant one, typing can be quicker, so the best forms offer a forgiving text field and a picker together.
A calendar picker earns its place by preventing errors a text field invites: it kills format ambiguity (is 03/04 March or April?), blocks impossible or out-of-range dates, and shows which days are even allowed. But for a date you already know - a birth date, far in the past - free typing is faster, so offer both: a text field that parses generously, plus a picker to fall back on.
Typed, "03/04" could have meant March or April, and nothing stopped a date that doesn't exist. Picked from the calendar, there was no format to get wrong and no invalid day to choose - the constraint did the error-checking for you. The picker didn't add a step so much as remove a class of mistakes.
A picker is the constraint principle made visible. By only offering real, in-range days it prevents whole categories of error - impossible dates, the endless DD/MM-versus-MM/DD confusion, bookings in the past - before they can happen. That's cheaper and kinder than catching them with a validation message afterwards.
But a calendar isn't always the faster path. For a date you already hold in mind - especially a distant one like a date of birth - clicking back through months is slower than just typing it. The strongest pattern is both: a forgiving text field that parses what people type, with a picker on hand for browsing or uncertainty.
Pickers go wrong when they fight the user: a tiny tap target on mobile, no keyboard support, a default month miles from the likely answer, or no way to type at all. Constrain the choice, but keep it fast - sensible defaults, large targets, full keyboard access, and generous parsing behind it.