https://pikaday.dbushell.com Pikaday A friendly guide to front-end date pickers! Menu * Native * Separate * Masked * Ranges * FAQ Who needs a JavaScript date picker? The answer, in most cases, is nobody! Complex UI leads to more errors and abandoned forms. There can be easier ways to pick a date than a calendar widget. This guide provides alternate ideas and aims to send developers on a path towards user-friendly interfaces. Native date and time inputs If you absolutely must use a calendar widget then it's wise to use the native input. All modern browsers support native date and time inputs. Date input Date [ ] The date input type provides a native date picker. Time input Time [ ] The time input type allows users to specify hours and minutes. Datetime input Date and time [ ] The datetime-local input type combines both date and time. Why use native inputs Native inputs are super easy to implement with one line of code. The web browser handles many important details for developers: * Accessibility ^(mostly*) * Performance * Internationalisation Let browsers do the hard work! Browsers allow keyboard users to type numbers in sequence. Most browsers provide alternate UI for time and date selection like the classic calendar widget. They're not perfect but do you trust a JavaScript library to do better? ^*Oh dear! Even native date pickers have some accessibility issues. Who disables JavaScript? HTML elements require no JavaScript. Every script is a performance burden and presents an opportunity for a website to break. Although most users do not actively disable JavaScript there are many reasons JavaScript won't be available. Always consider progressive enhancement to ensure JavaScript is not a hard requirement. Separate inputs A single date picker can be tricky to operate. For memorable dates using separate inputs can improve usability. The example below is based on GOV.UK date input component. When was your passport issued? For example, 27 3 2007 Day [ ] Month [ ] Year [ ] Select elements If only a limited set of data is valid then using select elements may be suitable. They can require fewer interactions to use and they eliminate typing errors. Select expiry date Month [January (1) ] Year [2025] Numeric month labels can be helpful but take care in how they're written. Screen readers may mistakenly announce "1 January" as "the 1st of January", for example. Select departure time I'm leaving [Today ] Hour [09] Minutes [00] Travel booking often has a fixed schedule with limited time options, such as every 15 minutes. Relative dates like "Today" and "Tomorrow" can be easier to understand. Additional attributes * The inputmode="numeric" attribute allows devices to prefer a numeric keypad * The number input type is not necessarily the best choice for all numeric data * The maxlength attribute can restrict input (e.g. 2 characters for day/month and 4 for year) * The pattern attributes combined with :user-invalid allows instant validation feedback * The autocomplete attribute can prefill dates like the user's birthday * The min and max attributes allow for date and number contraints Masked inputs Another common alternative to date pickers is a single input with a placeholder mask. This can be used for full or partial dates. JavaScript can enhancement the experience. Expiry Date (MM/YY) [ ] Date of Birth (DD/MM/YYYY) [ ] The examples above provide client-side validation with errors such as "Please enter a valid day for February (1 to 28)". Valid dates are confirmed in full and formatted with the Intl API. Caution! Updating input values with JavaScript can break native undo/ redo. It's even possible to visually combined mutliple inputs using CSS to appear as one. Date of Birth (DD/MM/YYYY) Day [ ] Month [ ] Year [ ] Careful consideration The placeholder attribute should never be used alone. Always include a permanent label element that describes the field and expected format. Depending on design the individual labels may be inclusively hidden for assistive technology. Date formats vary by region. The United States notably prefer month/ day (MM/DD). If your website is used internationally a masked input may cause confusion. Be kind when parsing user input. Allow for a variety of separators, e.g. forward slash, hyphen, or whitespace. Accept an optional zero prefix, e.g. parse "01" as "1". Only use a two-digit year for future dates. If the current year is 2025 the input "31" means 2031. Lower numbers like "14" will jump ahead to 2114. This is more obvious near the end of the century! Ranges and limited options JavaScript date pickers that support range selection across two calendars are difficult to use, especially without a pointer. Consider providing two inputs instead to reduce complexity. If users are required to select an available date then a group of radio inputs can do the job. The example below illustrates the idea but is not fully interactive. Find appointment date Select a date range to find available options Start Date [2026-07-01 ] End Date [2026-08-31 ] Available options Choose one of the following dates for your appointment ( ) 1 July 2026 ( ) 14 July 2026 ( ) 21 July 2026 ( ) 12 August 2026 ( ) 30 August 2026 There are many design variations of this pattern. This idea is to replace complicated UI with a series of simple tasks. Such a pattern can be implemented as a multi-page form with JavaScript used to enhance it into a single page interactive experience. Frequently asked questions What if I use a JavaScript framework like React? All good JavaScript frameworks allow you to use native HTML elements. Not everything needs to be a custom component. Native input events can integrate with framework callbacks. Use attributes like value for two-way state binding. How do I style the native date picker? The on-page input element can be partially styled but other parts are not stylable. That is a good thing! Native system UI is familiar to the user. The design will differ based on operating system and input method. Date pickers even look different across browsers and that's fine too, you don't need to add yet another design to the mix! A stakeholder is demanding a JavaScript date picker, how do I dissuade them? Remember: the end goal is a successful form submission. Complex and fragile UI leads to more errors. All date pickers have accessibility issues. Combining basic inputs can be more user-friendly. Untested JavaScript UI may fall foul of regulation like the European Accessibility Act. Keep it simple for success! How do I test and guarantee accessibility? It's critical to understand the relevant accessibility guidelines. You don't need to memorise WCAG but there are no shortcuts to learning the important parts. Leverage existing web standards to avoid mistakes trying to code custom UI. Browser dev tools have built-in accessibility features to help identify mistakes. However, no tool is perfect. The only way to know for sure is to conduct user testing. Accessibility overlays are strongly discouraged and can make matters worse. Where can I learn more about date picker accessibility? * Collecting dates in an accessible way by Graham Armfield * What makes an accessible date picker? Is it even possible? by Russ Weakley * Maybe You Don't Need a Date Picker by Adrian Roselli * Date Picker Dialog Example by ARIA Authoring Practices Guide * Designing The Perfect Date And Time Picker by Vitaly Friedman This is all great but can you please recommend a JavaScript date picker? Sorry, no! There is no universal solution and all date pickers have issues. I hope this guide has given you the knowledge to evaluate your own requirements. Try to achieve your goal in the simplest way. A date picker is probably not the answer. Before you go! Remember to test and gather feedback from real users :) This guide is a work in progress, feedback is welcome! (c) 2025 Made by David Bushell Last updated 2025-11-10 Icons by Solar Icons (CC Attribution License) Find the original Pikaday on GitHub