sweetalert2-react-content and the gap between a React tree and a modal

SweetAlert2 renders markup, and React renders components

The problem this package solves is a mismatch of models. SweetAlert2 is a JavaScript library that shows a modal dialog in the DOM, and its content options are strings of HTML or text. React, on the other side, builds a tree of components and expects to own the rendering of that tree.

So when a dialog needs to show something interactive, the usual workarounds are unpleasant. You can hand-write an HTML string and lose every component you might have wanted, or you can build the dialog contents by hand outside SweetAlert2 and lose the modal behaviour.

sweetalert2-react-content closes that gap by rendering your React element into the dialog. The package describes itself as the official SweetAlert2 enhancer adding support for React elements as content, and the README links three recipes on the SweetAlert2 site that show the same idea in practice: a simple example, an example with React Router, and one with the react-day-picker component.

Those three recipes matter for scope. This is a bridge for dialog content, not a React rendering strategy for the whole application.

withReactContent returns a subclass, not a wrapper object

The API is a single call. You pass SweetAlert2 in, and you get back something that behaves like SweetAlert2:

import Swal from 'sweetalert2'
import withReactContent from 'sweetalert2-react-content'

const MySwal = withReactContent(Swal)

MySwal.fire({
  title: <p>Hello World</p>,
  didOpen: () => {
    // `MySwal` is a subclass of `Swal` with all the same instance & static methods
    MySwal.showLoading()
  },
}).then(() => {
  return MySwal.fire(<p>Shorthand works too</p>)
})

The comment in the README states the design decision outright: `MySwal` is a subclass of `Swal` with all the same instance and static methods. That is why `MySwal.showLoading()` works inside `didOpen`, and why the returned promise behaves the way a normal `Swal.fire()` promise does.

The subclass approach is the reason there is no separate API to learn. You keep using the SweetAlert2 methods you already know, and only the content changes shape. It also means the enhancer can be applied to a SweetAlert2 instance you have already configured, for example one with global mixins or custom defaults, rather than requiring you to rebuild your setup.

Nine options accept React elements, and the list is closed

The README states which options can be React elements, and the list is finite: `title`, `html`, `confirmButtonText`, `denyButtonText`, `cancelButtonText`, `footer`, `closeButtonHtml`, `iconHtml` and `loaderHtml`.

Nine is enough to cover the interesting cases. The title and body carry the main content, the three button labels let you put components in the action area, `footer` covers the auxiliary area, and `closeButtonHtml`, `iconHtml` and `loaderHtml` cover the decorative parts, which is where a custom close icon or a spinner would otherwise be awkward to express.

What is not on the list is worth noticing. The dialog is still a SweetAlert2 dialog with SweetAlert2's own DOM structure and its own CSS classes, and the React element is rendered inside it rather than replacing it. If you are expecting to build an entire modal in React and hand it to this package, that is not what it does. The README does not document any lifecycle behaviour for the React tree, such as unmounting after the dialog closes, so treat the component as mounted for the duration of the popup.

Shorthand form passes the element as the whole argument

The example above contains a second form worth pulling out, the shorthand where the React element is passed as the argument to `fire()` itself, so `MySwal.fire(<p>Shorthand works too</p>)` opens a dialog whose content is that element.

That is the equivalent of using the element as the `html` option. It reads well for a one line message, though it is worth being consistent about which form you use in a codebase, because mixing `title`, `html` and the shorthand in the same file makes the dialog content harder to find when you come back to it.

The `didOpen` callback in the example shows the other half of the integration. SweetAlert2 lifecycle hooks still fire, so you can call `showLoading()` while some data loads and close the dialog when the data arrives. Nothing about using React elements removes the imperative SweetAlert2 API.

Installing means two packages, and the peer ranges are narrow

The installation command installs both the library and the enhancer:

npm install sweetalert2 sweetalert2-react-content

The enhancer has no runtime dependencies of its own. `package.json` lists an empty `dependencies` object and puts everything in `peerDependencies`:

  "peerDependencies": {
    "react": "^18.0.0 || ^19.0.0",
    "react-dom": "^18.0.0 || ^19.0.0",
    "sweetalert2": "^11.0.0"
  },

That is the practical constraint of the package. React and react-dom must be on version 18 or 19, and SweetAlert2 must be on version 11. An application still on React 17 or on SweetAlert2 10 is excluded by the peer ranges, and there is no compatibility shim for those versions.

The peer dependency design also means the enhancer does not duplicate SweetAlert2 in your bundle. It expects the same copy your application already uses, which is what allows the subclass to share the same configuration and the same DOM behaviour.

A UMD build exists for script tag setups

The package publishes three builds. The `main` entry is `dist/sweetalert2-react-content.cjs.js` for CommonJS, the `module` entry is `dist/sweetalert2-react-content.es.js` for bundlers, and the `browser` entry is `dist/sweetalert2-react-content.umd.js`. TypeScript types are shipped from `src/sweetalert2-react-content.d.ts`.

The README calls out the UMD file specifically: it defines `window.sweetalert2ReactContent` in non-CJS/AMD environments. That is the path for a page loading the library from a script tag rather than from a module system, which is a small but real consideration for a package that otherwise assumes a modern bundler setup.

The repository shows a modern toolchain around it. The build runs on Rollup, the tests run headless in Cypress, the linter is oxlint with oxfmt for formatting, and there is a `bun.lock` and `bunfig.toml` alongside the package manager configuration. A `release.config.js` and a `CHANGELOG.md` indicate releases are driven by a release configuration rather than by hand.

Version 5 of the enhancer, and a maintenance cadence to plan around

The enhancer is versioned separately from SweetAlert2 itself, which is a point worth keeping straight. The current package version is 5.1.2, released on 2026-03-15. Before that came v5.1.1 on 2025-12-13 and v5.1.0 on 2024-12-16, and the last push to the repository was on 2026-05-13.

That cadence suggests a small package with occasional releases rather than a rapid stream, which is what you would expect for something whose entire job is to bridge two libraries. The risk to plan for is not churn in this package but a major version bump in SweetAlert2 itself, since the peer range pins `^11.0.0` and a SweetAlert2 12 would not satisfy it.

The licence is MIT, declared in `package.json` and with the text in the LICENSE file. The author listed in the package manifest is Matthew Francis Brunetti, and the package is published under the sweetalert2 organisation, which is what the official enhancer designation means in practice: it is maintained by the same organisation as SweetAlert2 rather than by a third party.

Editorial conclusion

sweetalert2-react-content is worth adding when a SweetAlert2 dialog needs to show a real React component, such as a router link or a date picker, and when you already depend on SweetAlert2 in a React application. It is the wrong tool for a project that is not on SweetAlert2 11 with React 18 or 19, and for dialogs where a plain HTML string would do, since the enhancer adds a peer dependency and a wrapper without buying anything there. Verify first that the content you want to render appears in the list of supported options, `title`, `html`, `confirmButtonText`, `denyButtonText`, `cancelButtonText`, `footer`, `closeButtonHtml`, `iconHtml` and `loaderHtml`, and that the SweetAlert2 major version in your app satisfies the `^11.0.0` peer range.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. sweetalert2/sweetalert2-react-content on GitHub