react-day-picker vs react-datepicker vs MUI X Date Pickers in 2026

Quick answer (October 2026). react-day-picker is a calendar, not a date input, and it is what shadcn/ui installs when you add a Calendar. react-datepicker is the complete input-plus-popover widget, and it ships as one pre-bundled 290 KB ES module that your bundler cannot take apart. MUI X Date Pickers is the most capable and the most demanding: it will not run until you have also adopted MUI and chosen one of eight date adapters.

Every number below was measured against live registry, repository and tarball state on 7 October 2026. Nothing here is copied from another comparison page, and where our first measurement was wrong we have said so and shown the correction.

The download counts do not mean what they look like

Weekly downloads for the seven days ending 29 September 2026, straight from the npm downloads API:

Read naively that says react-day-picker is nine times more popular than either rival. It does not.

Fetch the shadcn/ui registry entry for its Calendar component and the dependency list is explicit:

"dependencies": ["react-day-picker@latest", "date-fns"]

Every shadcn add calendar, in every project, pulls react-day-picker. shadcn is the dominant way React components get added to a Next.js app in 2026, so a very large share of that 53.9 million is a component-registry side effect rather than a developer comparing three libraries and picking one.

The honest bound: this evidence shows the mechanism exists and is first-party documented. It does not let us put a number on the share. What it does establish is that you cannot use the download gap as an argument in this decision, in either direction.

npm's size column ranks all three in the wrong order

The registry reports unpackedSize for each published tarball. Here is what it says, and what a bundler actually walks:

The registry puts react-datepicker first and react-day-picker last. On the ES module graph, the top and bottom swap places. Three different inflators are responsible, and they are not the same one:

• react-datepicker publishes 2,044,976 B of source maps and, separately, its own TypeScript source: 67 .tsx files totalling 1,034,846 B plus 29 .ts files at 202,549 B. That is 3.28 MB of a 4.50 MB tarball, 72.9 percent, that no bundler ever reads.
• @mui/x-date-pickers publishes 1,164,437 B of .d.ts across 676 files, 31.3 percent of its tarball, and ships no source maps at all.
• react-day-picker publishes 280,898 B of .d.ts across 407 files, 28.3 percent, and also ships no maps.

Shipped TypeScript source is the inflator we had not seen before. Source maps and type declarations are both familiar; a package publishing its entire src directory alongside dist is a third mechanism, and on this comparison it is the largest single one.

The number that decides your bundle is whether the graph can shrink

Resolve each package's ESM entry from its own module or exports field rather than from a filename pattern, then look at what sits behind it:

react-datepicker's ESM "entry" is the whole library. One file, two export statements, one relative import. A bundler can do dead-code elimination inside it, but it cannot drop modules from a graph that has no modules. Whatever fraction of those 290 KB your import reaches comes along, and that fraction is close to fixed no matter how little of the library you use.

The other two are barrels. react-day-picker's 396-byte entry re-exports from 202 files; MUI's 2,070-byte entry re-exports from 338 and declares sideEffects: false, which is the strongest signal a package can give a bundler that nothing may be kept for its side effects alone.

So the smallest ESM graph belongs to the library least able to get smaller. That inversion is the practical headline of this comparison.

What each one makes you install alongside it

Both standalone libraries now hard-depend on date-fns 4, so the old "bring your own date library" framing no longer applies to either. react-datepicker additionally pulls @floating-ui/react to position its popover, which is reasonable given it owns a popover and the other two do not.

MUI is a different shape of commitment. @mui/material and @mui/system are not marked optional in peerDependenciesMeta, so they are genuinely required. On top of that the package declares eight optional date adapters: dayjs, luxon, moment, date-fns, moment-hijri, moment-jalaali, date-fns-jalali and the Emotion pair. All eight are optional individually, which means npm will let you install the package with none of them and nothing will work. "Choose exactly one of these eight" is a real constraint that the manifest format cannot express, and it is the single most common way a first MUI picker install fails.

Accessibility, after three corrections to our own instrument

This section is the one where our first three readings were all wrong, all in the same direction, and all against react-day-picker. We are showing the corrections because the naive numbers are the ones most likely to be repeated elsewhere.

Wrong reading one. Counting onKeyDown attachments in the shipped ESM gives react-day-picker 1, react-datepicker 20, MUI 42. That looks like a 42-to-1 difference in keyboard support. It measures handler attachments, not keyboard coverage.

Wrong reading two. Searching for quoted key names returns zero keys for react-day-picker. That is a parse failure, not a result: react-day-picker stores its key map as unquoted object keys inside a keyMap literal, so a quoted-string matcher is structurally blind to it.

Wrong reading three. A loose aria-[a-z]+ pattern reported aria-labels as an attribute react-day-picker uses. It is JSDoc prose in eleven files under labels/, describing functions that generate ARIA labels. Not an attribute.

Here is the corrected measurement, matching both quoted strings and unquoted object keys:

All three handle the same eight grid-navigation keys: the four arrows, Home, End, PageUp and PageDown. react-datepicker and MUI add Enter, Escape, Tab and one deletion key on top, and the reason is structural rather than a quality difference: both own a text input and a popover that have to be opened, dismissed and cleared. react-day-picker owns neither, so it has nothing to dismiss.

react-day-picker is in fact the richest of the three on pure grid movement. It uses shiftKey six times against one each for the others, switching granularity so that shift-arrow jumps a month or a year rather than a day or a week.

It also carries the keyboard semantics in the markup rather than in JavaScript. Its day cells are native button elements inside role="grid", with role="gridcell", role="rowheader" and a role="status" live region. The DayButton component is four lines of substance: it focuses itself when the focused modifier is set, and otherwise renders a plain button. Activation with Enter and Space is the browser's job, which is why there is no Enter handler to count.

MUI's nine extra ARIA attributes are mostly not about the calendar. They are the spinbutton family, aria-valuemin, aria-valuemax, aria-valuenow, aria-valuetext, plus aria-colindex and aria-rowindex, and they exist because MUI ships a segmented text field where you arrow through day, month and year sections. That is a genuinely larger accessible surface, because it is a genuinely larger component.

Maintenance, and one timestamp that is a robot

react-datepicker's pushed_at of 2 April 2026 reads like activity. It is not. The repository activity feed shows the eight most recent events are all branch_creation and branch_deletion on dependabot/npm_and_yarn/... refs, the last of them a lodash bump. An unattended Dependabot schedule keeps pushed_at warm indefinitely on a repository nobody is committing to.

The default branch tells a different story: its newest commit is 5 January 2026, and two of the three newest are Dependabot merges. There is no next or beta dist-tag on npm, so there is no in-flight release either. Twelve of the first twenty-five branch names are Dependabot branches, out of at least a hundred.

updated_at is worse than useless here. It reads within the last day for all three repositories, which would paint a library with no commits in nine months as active.

The milder reading, and it is the correct one. react-datepicker is not dead. It carries no deprecation notice on npm, it is not archived, it has the most stars of the three and six million weekly downloads, and 9.1.0 works. What it has is no release in roughly ten months, no human commit in nine, 65 open pull requests and 36 open issues. That is maintenance drift, and the risk it creates is specific: if React or date-fns ships something that breaks it, there is no evidence anyone is positioned to respond quickly.

The issue count that is nearly five times too big

open_issues_count on the GitHub API includes pull requests. On these three it reports 12, 101 and 1,172, which split into 5 issues plus 7 PRs, 36 plus 65, and 1,059 plus 113.

That 1,059 is not MUI X Date Pickers. mui/mui-x is a monorepo holding the Data Grid, Charts, Tree View and the pickers. Filtered by label, the open issues are 585 for the data grid, 226 for the pickers and 86 for charts. Quoting 1,059 against the date pickers overstates it by a factor of 4.7.

Our first attempt at that filter returned zero for all three component labels against a known total of 1,059, which is the signature of wrong label names rather than of zero issues. The prefix is scope:, not component:.

226 open issues is still an order of magnitude more than react-day-picker's 5, and that comparison is fair as far as it goes. But the surfaces are not comparable: MUI's pickers cover date, time, datetime and range variants across eight adapters and 42 translated locales, against one calendar component.

Licensing, and why a scanner will tell you MUI X is unlicensed

All three ship a complete, unmodified MIT licence inside the published tarball. We read the files rather than the registry metadata.

GitHub nonetheless reports spdx_id: None for mui/mui-x. The mechanical reason, confirmed through the contents API rather than by guessing a path: the repository root has 44 entries and no licence file of any name. The other two repositories both have one.

The missing root licence is not an oversight. The same repository publishes @mui/x-date-pickers-pro, whose manifest declares "license": "SEE LICENSE IN LICENSE" and which describes itself as the Pro plan edition. A mixed-licence monorepo cannot put a single SPDX identifier at its root, so it puts none, and the scanner reports the whole thing as unknown.

If a licence audit flags MUI X Date Pickers, that is a scanner artefact. The community package you install is MIT. The practical boundary worth knowing is a packaging one rather than a licensing one: single date and time pickers are in the MIT package, and the range pickers live in the separately licensed Pro package.

Internationalisation means three different things here

• react-day-picker re-exports 95 date-fns locales from react-day-picker/locale. That is date formatting and parsing. Its own interface labels are English defaults you override through the labels prop, which is what those eleven labels/ modules are for.
• @mui/x-date-pickers ships 42 locale files of its own. These are translated interface strings and ARIA text, not date formatting. It is the only one of the three that hands you a translated accessible name out of the box.
• react-datepicker ships zero locale files. It delegates date formatting entirely to date-fns locales you import yourself, and has no built-in interface translations at all.

A team that needs a German calendar with German screen-reader labels gets the most from MUI with the least work. A team that only needs German date formatting is equally served by any of them.

So which one

Pick react-day-picker if you are already on shadcn/ui, if you want to own the markup, or if bundle cost scales with how much you use. You get a calendar, native button semantics, full grid navigation with granularity modifiers, 95 date locales, five open issues and a release last week. You do not get an input, a popover, time selection or a range picker without building them.

Pick @mui/x-date-pickers if you have already adopted MUI, if you need date plus time plus a segmented accessible field, or if translated ARIA labels matter. It is the largest ESM graph of the three at 1.04 MB, but it declares sideEffects: false over 338 modules, so what you actually pay tracks what you import. Budget for the adapter decision before you start.

Pick react-datepicker if you want the complete widget today with no assembly and you are comfortable with a library in maintenance drift. It is the fastest route from zero to a working date input. Accept that the 290 KB module is close to all-or-nothing, and that nobody has merged a human commit since January.

Avoid react-datepicker specifically if you expect to be on a React or date-fns major upgrade path in the next year and cannot absorb maintaining a fork.

Limitations

We did not measure gzipped or brotli-compressed bundle output, and we did not run a real bundler over a real import graph, so the ESM figures above are the raw bytes available to a bundler rather than what lands in your build. We did not audit either library against WCAG with a screen reader; the accessibility section measures the ARIA surface and keyboard key coverage present in the shipped code, which is a proxy and not a conformance result. We did not evaluate the Pro package, and we quote no prices anywhere, because plan pricing changes faster than this article will.

Related reading from the gallery: our comparison of React icon libraries covers the same tree-shaking question on a much larger module count, and our React form library comparison covers the state layer a date picker usually plugs into.