Use a date component when a person needs to provide a calendar date. It supports separate day, month and year inputs or a single field with a date picker, as well as limits and comparisons with another date.

Choose the date format and interaction style for the people using the service. Date formats are not universally interpreted in the same order, so state the expected order plainly wherever there is any risk of ambiguity.

Choose a date input style

flowchart TD
  A[What date is needed?] --> B{Is it likely to be in the past or well known?}
  B -- Yes --> C[Use separate day, month and year inputs]
  B -- No --> D{Does choosing from a nearby calendar help?}
  D -- Yes --> E[Consider a date picker with typed input]
  D -- No --> C

Explain the expected date

Make the question specific: “What date did the incident happen?” is clearer than “Date”. In the hint, show the expected format using a real, unambiguous example such as 08 04 2026 and label the order where necessary.

If an exact date is not known, do not silently force people to invent one. Consider whether the service should collect only a month and year, an approximate date, or an explanation instead.

Set sensible boundaries

You can limit how far into the past or future an entered date may be. These limits are measured from the date the person visits the service.

Use them only when there is a clear service rule:

• A booking date might be limited to the next 90 days.
• An incident date might be limited to the previous year.
• A date of birth normally needs a different rule from a recent-event date.

Tell people about a boundary before they encounter an error. For example, “Choose a date in the next 90 days” is better than an unexplained rejection after they select a date.

Compare two dates

A date component can be validated against another date component. Use this for rules such as an end date being the same as or after a start date, or a requested date being after a previous event.

flowchart LR
  A[Enter start date] --> B[Enter end date]
  B --> C{End date is on or after start date?}
  C -- Yes --> D[Continue]
  C -- No --> E[Show a specific correction message]

Use a clear error message that states the relationship: “End date must be on or after the start date.” Test both the same-date boundary and values on either side of it.

Avoid comparing dates that can be omitted unless the validation message explains exactly what needs to be completed first.

Pre-populate with care

Pre-population can provide a date from earlier answers or from trusted data. It is appropriate for a calculated or known date, but it must not look like a person’s confirmed answer if they have not reviewed it.

If the date can be amended, provide an obvious way to do so. If it becomes invalid because an earlier answer changes, reset it deliberately and test a returned page and resumed draft.

Review and accessibility

On a review page, make the label specific enough to distinguish multiple dates, for example “Date you moved” and “Date of birth”. Ensure the displayed answer uses an understandable calendar date, not a raw internal value.

Do not rely on a calendar icon, colour or placeholder alone to explain how to enter the date. Check keyboard entry, error focus and small-screen behaviour.

Testing checklist

• The label identifies the event or purpose of the date.
• The hint states an unambiguous date order where needed.
• Typed entry works even when a date picker is available.
• Empty, invalid and impossible dates produce helpful errors.
• Past and future limits match the actual service rule.
• Date-to-date comparisons work at the boundary and on both invalid sides.
• Pre-filled dates can be reviewed, changed or reset as intended.
• Review pages show a clear, human-readable date.

Related guidance

• Shared component settings
• Time components
• Text components
• Design accessible services