React Email Editor
MIT-licensed React component that embeds Unlayer's drag-and-drop email builder inside your own product
React Email Editor is a React component that drops a drag-and-drop email builder into your own app, so your users can design emails without you building an editor. The component is MIT-licensed, installs from npm in one line, and has 5,206 GitHub stars as of August 2026 — but the editor it renders is Unlayer's hosted product, which is the distinction the licence badge hides. It decides how fast you can ship email templating; it decides nothing about whether the resulting emails get opened.
What it is, precisely
React Email Editor (github.com/unlayer/react-email-editor) is the official React wrapper for Unlayer's visual email builder. You render a single editor component, hold a ref to it, and work through three methods the README documents: loadDesign puts a saved template back on screen, saveDesign hands you the design as JSON, and exportHtml returns responsive HTML plus that JSON. Your database stores the JSON so a user can edit later, and the HTML so your sending pipeline has something to deliver. The repo has been going since 2017 and is comfortably maintained: v2.1.2 shipped on 11 August 2026, and the substantive work behind it was a real fix rather than housekeeping — a server-side-rendering hydration bug and a long-standing leak where editors were never destroyed on unmount.
Version 2 is a modernisation release, and its own upgrade notes are unusually candid about what changed: React 16.8 and Node 18 are now the floor, deep imports into the package internals are blocked by an exports map, and the published code is ES2019, so an old toolchain that cannot parse it should stay on the 1.x line. The bundle carries the "use client" directive, which means Next.js App Router users can import it straight into a Client Component instead of reaching for the usual dynamic-import workaround. The rendered output is checked against Gmail, Apple Mail, Outlook and Yahoo Mail — the four clients where hand-written email HTML most often falls apart.
Open-source component, hosted editor — read the licence line twice
The repository is MIT and the README says so plainly, but MIT covers the React component, not the editor it loads. This is a common shape in developer tooling and it is worth being deliberate about, because "open source" on the badge and "open source" in your risk register are answering different questions. Here is what sits where.
| What you are getting | Where it lives | What that means for you |
|---|---|---|
| The React component | Your repo, from npm, MIT | Yours to fork, patch and pin. Nothing here can be taken away. |
| The editing UI, tools and AI assistant | Unlayer's service, loaded at runtime and configured through the component's options | Your users' ability to edit depends on a third party being available, and the feature set follows that vendor's roadmap rather than your repo. |
| The exported HTML and design JSON | Your database | The portable part. Templates already created remain yours even if you change editors later. |
| Translations of the editor UI | A separate Unlayer repository that accepts pull requests | You can contribute a language, but you are contributing it upstream, not shipping it locally. |
Where an email builder belongs in a founder's growth stack
The question to settle before installing anything is whose emails these are. If your users compose and send email inside your product — a CRM, a newsletter tool, a booking system that sends confirmations somebody wants to brand — then an embedded builder is close to unavoidable, and building your own is months of work that has nothing to do with why anyone bought your product. If it is only your lifecycle and transactional mail, you do not need a visual editor at all: code-authored templates like React Email are less work and version far better.
- It solves production, not distribution A builder makes emails faster to create. It has no opinion about who receives them, whether the address is deliverable, or whether the message was worth sending.
- It moves a queue off your desk The real win when your users are the authors is that template requests stop arriving as engineering tickets — which is a support-load argument, not a growth one, and it is fine to buy it on those terms.
- It does not decide open rates Layout is the one part of email performance that is largely solved. Subject line, timing, list quality and reputation are the parts that are not, and none of them appear in an editor.
- It adds a runtime dependency An embedded hosted editor is a third party inside your product's critical path. Worth accepting knowingly, and worth checking that saved designs remain openable if you ever stop paying for it.
Our own experience running email at AgentCeres — the AI Growth Officer, at agentceres.com — points the same way, and the two things that mattered were neither layout nor tooling. The first was subtraction: a person who signed up and stayed in the product for a few minutes could receive three near-identical messages inside about five minutes, once the automated first research landed on top of the welcome and trial notes. We deleted an email rather than designing a better one. Production was never the constraint; restraint was. The second was language. Every automated message we send carries hand-written variants for the markets we serve rather than machine translation, because the machine-translated pass read exactly like a machine-translated pass — and that is the work no drag-and-drop editor of any quality would have helped with. Choose the builder for whose hands are on it, then spend the time you saved on lifecycle emails that are worth receiving.
FAQ
- Is React Email Editor free?
- The React component in the repository is MIT-licensed and free to use. The editor it embeds is Unlayer's own product, so the terms and any limits for the editor itself are set by Unlayer and are separate from the repository's licence. Read both before you build a paid feature on top of it.
- How is it different from React Email?
- React Email is for emails you write: components in your codebase, compiled to HTML, reviewed in pull requests. React Email Editor is for emails your users write: a visual canvas inside your product that returns HTML and a design JSON. Different audiences, and most products need only one of them.
- Does it work with the Next.js App Router?
- Yes. The README states the published bundle includes the "use client" directive, so it can be imported directly from a Client Component with no dynamic-import workaround. The editor still renders into the DOM, so it remains client-only by nature.
- Does it send the email?
- No, and that boundary is worth keeping clear. It produces HTML and a design JSON. Delivery, list management, suppression and sender reputation belong to a sending stack — a self-hosted option like listmonk or an email API — and those are the parts that decide whether the message reaches an inbox at all.
- What breaks when upgrading from version 1?
- The component API is unchanged, so most apps upgrade without touching code. The requirements moved: React 16.8 and Node 18 are the minimum, deep imports into the package internals are now blocked, and the shipped code is ES2019. The v2 release also began destroying editors on unmount, which fixes a leak but is a behaviour change worth knowing about if anything in your app depended on the old lifecycle.
You built it. Now grow it.
AgentCeres is a managed AI marketing team — specialists draft the SEO, social, and outreach that fill your links, you approve what ships. 14-day free trial, from $39/month.