Sonner vs react-hot-toast vs react-toastify for Next.js in 2026

Quick answer (September 2026). These three are not the three-way tie that download counts suggest. Measured live from the npm registry, the published tarballs and the GitHub API on 23 September 2026: Sonner is downloaded 37.9 million times a week, roughly thirteen times the other two combined, and almost all of that is one integration rather than one decision. react-hot-toast is the smallest by a wide margin at about 3.8 KB gzipped, is the only one of the three that still supports React 16 and 17, and shipped a release seven days ago. react-toastify is the oldest, needs a stylesheet import the other two do not, and has by some distance the richest accessibility surface. Pick react-hot-toast when bundle weight or an older React version is the binding constraint, Sonner when you are already inside the shadcn ecosystem, and react-toastify when the notification region has to be genuinely operable by keyboard and screen reader.

The download number is not a popularity contest

Start with the figure that dominates every comparison of these libraries, because it is the one most likely to make you choose wrongly.

Weekly downloads, read from the npm downloads API on 23 September 2026:

For scale, and measured in the same pass so the comparison is like for like: react itself is 132.7 million, next is 42.7 million, @radix-ui/react-dialog is 53.1 million. Sonner at 37.9 million sits at roughly 89 percent of Next.js. A toast library does not reach that number on merit alone.

The mechanism is a single line in a registry file. Fetch https://ui.shadcn.com/r/styles/new-york/sonner.json and the component declares dependencies: ["sonner", "next-themes"]. Sonner is what you get when a shadcn project adds a toast, and shadcn is installed into an enormous share of new Next.js applications. The download curve is measuring shadcn adoption with a toast library attached to it.

That matters because it means the number tells you almost nothing about whether Sonner is the right fit for a project that is not already on shadcn. Two of the three libraries here are chosen deliberately. One is mostly inherited.

What shadcn actually ships today, which is more interesting than it looks

This is the part worth getting right, because the obvious reading is wrong and the wrong version has real consequences.

Probe the shadcn docs today and /docs/components/sonner and /docs/components/toast both redirect to /docs/components/base/toast. That page is a Base UI toast. Searching its rendered text for "sonner" returns zero occurrences. On its own that reads like a clean story: shadcn has moved off Sonner, so the 37.9 million figure is about to unwind.

It is not that, and the correction came from one more request. The Toast documentation now carries three variants, Base UI, React Aria and Radix UI. Fetch the Radix one at the shadcn Radix toast page and it says, verbatim: "The toast component has been deprecated. Use the sonner component instead." Sonner is still listed in that variant's component sidebar, between Slider and Spinner, and /docs/components/radix/sonner still returns HTTP 200.

The registry agrees. As of 23 September 2026 sonner.json resolves and still declares the sonner dependency. A sibling toast.json also resolves and declares @radix-ui/react-toast instead. A base-toast.json does not exist.

So the honest statement is narrower and more useful than "shadcn dropped Sonner". shadcn is part-way through a move to Base UI. On the Radix line, which is where the large existing installed base lives, Sonner is not merely present, it is the explicitly recommended replacement for a deprecated component. On the Base UI line, which is now the default destination for the bare toast URL, you get a Base UI toast and Sonner is not mentioned at all.

The practical consequence for a new project in late 2026 is that which toast you inherit depends on which variant your project is configured for, and the default has quietly changed. If you assumed shadcn add toast still means Sonner, check.

The size comparison everyone quotes is measuring source maps

The second figure that circulates about these libraries is package size, and the usual source is npm's unpackedSize. Those values on the current stable releases are:

Read at face value that says react-toastify is more than three times the size of Sonner. It is not, and the gap is almost entirely an artefact of what each maintainer chooses to put in the tarball.

Extract the tarballs and measure by file type. react-toastify ships 363,885 bytes of source maps. react-hot-toast ships 128,931 bytes of source maps plus another 27,144 bytes of original TypeScript source. Sonner ships neither: no maps, no source, eight files. Source maps are roughly 64 percent of react-toastify's tarball and they never reach a browser.

unpackedSize is a fact about a tarball, not about an application. It is the wrong instrument for this question and it is the one almost every comparison reaches for.

Measured properly, Sonner is the largest of the three

Here is the number that actually predicts what lands in your bundle, taken from the ECMAScript module entry points in each published tarball.

The raw column overstates the gap and it is worth saying why rather than quoting it. Sonner's entry point is 1,241 lines: it ships unminified. react-hot-toast's is three lines, minified. Comparing 69,795 against 10,044 is comparing a minification setting, not a library.

Gzip is the fairer instrument because it absorbs most of the whitespace difference, and it still puts Sonner at about 14.5 KB against react-hot-toast's 3.8 KB. To bound the remaining doubt, collapsing Sonner's leading whitespace before gzipping only takes it from 14,545 to 13,648 bytes. Your bundler will minify it properly and do a little better than that, so treat roughly 3.6 times as the honest multiple rather than the seven times the raw bytes suggest.

Either way the ranking is stable and it is the reverse of the folklore. Sonner is widely described as the light modern option. By the only metric that reaches a browser it is the heaviest of the three, and react-hot-toast, the one whose search volume has fallen fastest, is dramatically the smallest.

One caveat that cuts the other way, and it is a real one: react-hot-toast achieves 3.8 KB partly by depending on goober, a CSS-in-JS runtime, so a small amount of its cost is a separate package rather than an absent cost. Sonner has zero runtime dependencies. react-toastify has one, clsx.

Accessibility is where the oldest library wins

Toast notifications are an accessibility problem before they are a styling problem, because a message that appears without focus has to be announced rather than seen. That is an ARIA live region, and the attributes are visible in the shipped code.

Grepping the published module entry points for live region attributes:

react-toastify sets aria-live to polite, aria-atomic to false and aria-relevant, carries six separate aria-label attributes including a labelled progressbar for the auto-dismiss timer ("notification timer") and a labelled container ("Notifications Alt+T"), and registers an Alt+T hot key to move into the notification region.

Sonner sets aria-live polite, aria-relevant to "additions text", aria-atomic false, and carries two aria-label attributes, one for the close button and one configurable container label.

react-hot-toast sets role to status and aria-live to polite, and that is the complete set. No aria-atomic, no aria-relevant, no aria-label anywhere in the shipped entry point.

This is the clearest inversion in the comparison. react-toastify is the library that gets dismissed as the legacy option, and it is the only one of the three that gives a keyboard user a documented way to reach the notification region and a screen reader a labelled timer. react-hot-toast's minimalism, which is what buys it 3.8 KB, is partly a minimalism of accessibility affordances.

None of the three is disqualifying. A polite live region is the core requirement and all three have one. But if the notifications carry anything a user must act on rather than merely notice, the attribute counts are not decoration.

Maintenance: a falling search curve is not abandonment

Search interest for react-hot-toast has fallen hard, from 720 monthly US searches a year ago to 170 in August 2026. react-toastify has fallen from 1,000 to 320 over the same period. The natural inference is that both are fading and Sonner has taken the category.

The repository state says something different. From the GitHub API on 23 September 2026:

react-hot-toast is the most recently active of the three. Version 2.6.1 landed on 16 September 2026, seven days before this was written. Sonner's last push was six weeks ago and its 2.0.8 release followed a twelve-month gap after 2.0.7. react-toastify has not been pushed in five months.

All three have slowed. None is abandoned, none of the repositories is archived, and all three carry a plain MIT licence read from the tarball rather than the registry field. The point is only that search decline measures attention, and attention is a lagging and noisy proxy for whether a maintainer is still shipping. On the evidence, the library with the steepest search decline is the one that shipped most recently.

Star counts are worth ignoring here. react-toastify leads on stars and is the least active; it has also been accumulating them since November 2016, against February 2023 for Sonner. Ten years of drift is not a signal about 2026.

The App Router details that actually cost you time

Three practical differences, all read from the published packages.

Stylesheet handling. Sonner injects its styles into document.head at runtime and also exports a dist/styles.css you may ignore. react-hot-toast uses goober and ships no stylesheet at all. react-toastify is the only one of the three that requires an explicit import of react-toastify/dist/ReactToastify.css, exposed as a dedicated export path. In the App Router that import has to live somewhere real, usually the root layout, which is one more file to touch and one more thing to forget.

Client boundaries. All three ship a "use client" directive at the top of their entry point. This is genuinely a non-difference and it is worth recording as such, because it is frequently presented as a differentiator. Every one of them is a client component and every one of them needs its provider mounted inside a client boundary. If you are weighing these three on React Server Component compatibility, that axis carries no information.

React version floors. Sonner and react-toastify both declare a peer range of React 18 or 19. react-hot-toast declares React 16 and above. If you are maintaining an application still on React 17, two of these three are off the table and the decision is already made.

For the shape of the tradeoff between an old library with deep configuration and a newer one with a smaller surface, the same pattern shows up in our React form library comparison, where the oldest option also turned out to be the one with the most complete escape hatches.

Release history, for the record

The licence column is the one axis here that does not discriminate at all. All three ship a plain MIT licence file with no commercial tier, no premium plugins and no usage condition. That is worth stating explicitly because it is unusual: in most component categories at least one candidate has an open-core edge somewhere, and picking the wrong one quietly commits you to a paid tier later. Not here. Whatever you choose, you can ship it in a commercial product without a second conversation.

How to choose

Choose react-hot-toast if bundle weight is a real constraint, if you are on React 16 or 17, or if you want the smallest possible surface. It is 3.8 KB gzipped against Sonner's 14.5 KB, and it is currently the most actively maintained of the three. Accept that you will be adding live region attributes yourself if the notifications matter.

Choose Sonner if you are already on shadcn and on the Radix variant, where it remains the documented recommendation. It has zero runtime dependencies, sensible live region defaults out of the box and by far the largest installed base. Verify which shadcn variant your project targets first, because the default toast has moved.

Choose react-toastify if accessibility is a requirement rather than an aspiration, or if you need the configuration depth that ten years and 123 releases produce. Budget for the stylesheet import and accept that its release cadence is the slowest of the three.

What none of the evidence supports is choosing on the download count. It is the largest number in this comparison and the least informative, and the integration that produced it has already begun to change underneath it.

Every figure in this article was read on 23 September 2026 from the npm registry, the npm downloads API, the published package tarballs, the GitHub REST API and the live shadcn registry, not from secondary sources. Package internals change; re-check before you commit.