Developer Tools

React Email

React Email turns React components into email HTML. Who maintains it, how it renders for Outlook, its Tailwind limits and its release status, with read dates.

Olivier Bazoud
November 5, 2026
8 min read

React Email is a library for writing an email as a React component and rendering it to an HTML string. You build the message from its unstyled components (Html, Container, Section, Button, Text, Tailwind and others) in a .jsx or .tsx file, then call render().

At a glance
Language
JavaScript, TypeScript (React)
License
MIT, free
Maintainer
Resend
Latest release
6.11.8 (2026-11-06)
Weekly npm downloads
7,921,788 (week to 2026-11-04)

Figures read on November 9, 2026.

Good fit
  • A JavaScript or TypeScript team that already writes React
  • Email templates in the same repository, with types
  • Any sending provider: render needs no account
  • Serverless functions such as AWS Lambda on Node.js: render is a plain async function
Not a fit
  • A backend outside JavaScript
  • A project that does not want React as a dependency

Minimal example

A template, then the render and plain-text calls, condensed from the project's Render documentation.

jsx
import * as React from 'react';
import { Html, Button, Hr, Text } from 'react-email';
export function MyTemplate(props) {
return (
<Html lang="en">
<Text>Some title</Text>
<Hr />
<Button href="https://example.com">Click me</Button>
</Html>
);
}
export default MyTemplate;
jsx
import { MyTemplate } from './email';
import { render, pretty, toPlainText } from 'react-email';
const html = await pretty(await render(<MyTemplate />));
const text = toPlainText(html);

render returns the HTML string and toPlainText derives a text version from it. The package is react-email on npm, and the code is on GitHub.

Pros and cons

Pros
  • Components, render and preview CLI in one package
  • Works with any provider, no account
  • Plain-text version with toPlainText
  • Built-in Tailwind component
  • Frequent releases, most downloaded on this list
Cons
  • JavaScript and TypeScript only, React required
  • Client support claimed, no published test matrix
  • render does not inline CSS
  • Tailwind component has documented limits
  • @react-email/components is deprecated

The details behind each point are in Limits and gotchas and Maintenance.

How it works

The points below come from the project's documentation and source, not from our own tests.

  • Tables: Section is built on a <table> element. The README says the components spare you "the mess of creating table-based layouts".
  • Inline styles: components emit inline style attributes. The documented render output shows style="font-size:14px;line-height:24px;margin:16px 0" on Text. The Tailwind component maps className utilities to styles on the elements.
  • Outlook conditionals: the Button component emits <!--[if mso]> blocks around its label and sets mso-padding-alt and mso-text-raise. No component emits VML: mso markup appears only in Button and Font.
  • Plain text: toPlainText(html) returns text, render accepts a plainText option, and data-skip-in-text="true" removes an element from the text output only.

The string is the HTML body alone. Your provider wraps it in a MIME part and adds the headers defined by the message format.

The preview side is a local app started with email dev. It watches your files and rebuilds on change, with --dir emails and --port 3000 as defaults. email build and email start build and serve the preview app, and email export writes static HTML files.

The docs treat render as the primary path and export as secondary. Version 5.0.0 added a dark mode switcher in the preview that emulates email client colour inversion.

JSX Email uses the same authoring model with its own maintainer. It has a page of its own.

Send it with an email API

render returns a string, so you can pass it to any provider. With the Nuntly TypeScript SDK:

TypeScript
import { Nuntly } from '@nuntly/sdk';
import { render } from 'react-email';
import { MyTemplate } from './email';
const nuntly = new Nuntly({ apiKey: process.env.NUNTLY_API_KEY! });
const html = await render(<MyTemplate />);
await nuntly.emails.send({
from: 'Acme <hello@example.com>',
to: 'jane@example.org',
subject: 'Welcome',
html,
});

The Send email from Next.js guide wires this into a server action.

If you use Better Auth, @nuntly/better-email is an open-source plugin with React Email and MJML renderers, covered in the Better Email guide.

Email client support

Claimed by the project
  • Gmail
  • Apple Mail
  • Outlook
  • Yahoo! Mail
  • HEY and Superhuman
  • Dark mode
Not published
  • Client versions tested
  • Test method
  • Dated test results

The list comes from the README, which says "All components were tested using the most popular email clients" and ticks those clients in a table. We did not run the tests.

Outlook on Windows is where a layout usually breaks. Only Button and Font carry Outlook-specific code (<!--[if mso]> spacers and mso-font-alt), the other components rely on table markup, and no component emits VML. render does not inline CSS, and Gmail caps a <style> block at 16 KB on desktop webmail. The dark: classes compile to @media (prefers-color-scheme: dark), which caniemail lists as unsupported in Gmail, Outlook on Windows and Yahoo! Mail. Before you ship, send a test to the clients your users read most, and look up any CSS property you depend on in caniemail.

Limits and gotchas

  • The Tailwind component in React Email supports only a subset of Tailwind. Classes copied from a Tailwind web app do not all carry over: React context does not cross the component, the prose class does not work, and space-* utilities do not work, and classes that need a selector more complex than a class lookup are not supported. pixelBasedPreset converts only font sizes and spacing, so breakpoints, border radius and max widths stay in rem, which Outlook on Windows and Yahoo! Mail do not support. Set those in px or in style props.
  • Responsive, hover and dark classes depend on a <style> block. Tailwind inlines plain utilities, but sm:, md:, dark: and hover: classes go into a <style> tag in the <head>, so <Head /> must sit inside <Tailwind> (it throws otherwise). Outlook on Windows ignores @media and :hover, and Gmail drops <style> for non-Google accounts in its apps, so design the inline version first and treat those classes as enhancements.
  • dark: classes do nothing in Gmail, Outlook on Windows or Yahoo! Mail, and the preview's dark toggle will not show them. They compile to @media (prefers-color-scheme: dark), which caniemail lists as unsupported in those clients. Since 5.0.0 the toggle only inverts inline colors to mimic client inversion, so make the light version readable on its own and test authored dark styles in Apple Mail or Outlook for Mac.
  • A clean preview is not a client test. email dev renders in a browser iframe, and its compatibility panel only checks your markup against caniemail data. Responsive classes worked in the preview and failed in Gmail until the 6.0.7 fix, so send real tests to the clients your readers use.
  • Code from before mid-2024 calls render without await. render became async in @react-email/render 1.0.0 (2024-08-22), and renderAsync was removed in 2.0.0 (2025-11-07). An old snippet that skips await gets a Promise, not HTML, so await render and replace renderAsync with it.

Maintenance

Active, with frequent releases: five majors between 2024-01-19 (2.0.0) and 2026-04-16 (6.0.0), and a commit on the default branch (canary) as recently as 2026-11-05.

  • Use npm for the version. GitHub's "latest release" badge points at @react-email/editor, because one release feed covers several packages.
  • Migrate off @react-email/components. Since 6.0.0 everything comes from react-email. The old package is flagged deprecated on npm but still had 11.9 million weekly downloads on 2026-11-05, so many projects have not moved yet.

Compare

Sibling tools in this catalog:

  • React Email vs MJML: components against markup, with the same template in both.
  • JSX Email: React components too, with its own maintainer and a UnoCSS-based Tailwind component.
  • MJML: XML-like markup compiled to HTML, with ports outside Node.
  • mjml-react: React components that compile through MJML.
  • Maizzle: Vue single-file components with Tailwind CSS.
  • Svelte Email: Svelte components.
  • @unitpost/email: JSX or TSX, or the same tags as a string with no build step.

The email frameworks hub lists every tool with its status.

FAQ

Do I need a Resend account to use React Email?

No. render returns an HTML string with no account, and the project's integration pages cover Nodemailer, Mailgun, SendGrid, Postmark and others besides Resend. Resend maintains the library.

What is the difference between React Email and JSX Email?

Both take React components and return an HTML string. React Email is maintained by Resend and had 7,921,788 weekly npm downloads on 2026-11-05. JSX Email has an individual maintainer, requires Node.js 22 and React 19.2 or newer in version 3, and had 97,446 weekly downloads on the same date. JSX Email adds a CLI check command and a VML fallback on Button, and its last release was 161 days old on 2026-11-05.

Does React Email support Tailwind?

Yes, through its Tailwind component, which maps className utilities to styles on the elements (tailwindcss 4.1.12 on 2026-11-05). The docs list four limits: no React context across the component, no prose class, no space-* utilities and no complex selectors.

Which package do I install, react-email or @react-email/components?

Install react-email. Since 6.0.0 (2026-04-16) it exports the components and the render utilities, and @react-email/components is flagged deprecated on npm. The deprecated package had 11,888,844 weekly downloads on 2026-11-05.

Is React Email still maintained?

Yes. The last commit was dated 2026-11-05, react-email 6.11.2 to 6.11.6 shipped between 2026-10-14 and 2026-10-29, and 6.11.8 followed on 2026-11-06. The repository is not archived.