react-email-editor: embedding Unlayer's drag-and-drop builder in a React app

What react-email-editor actually removes from your backlog

Building a visual email builder means maintaining a block model, a drag-and-drop layer, per-client HTML output, and a preview surface. react-email-editor does not implement any of that in the repository you install. It is the official React component for embedding Unlayer's drag-and-drop email editor in your app, and the README frames the use case plainly: template creation inside your app without building and maintaining a full visual editor from scratch.

The audience is therefore narrow and specific. It is a team that already ships a React product, wants end users to assemble email templates, and is willing to treat the editing surface as a third-party dependency. If you are generating email from hand-written JSX in a build step, this is not the same problem and this package will not help you. The repository is TypeScript, MIT licensed, and the last push was on 2026-09-10, with v2.1.2 released on 2026-08-11.

The component is a thin bridge to the Unlayer editor instance

The architecture is a wrapper, not an engine. You render an EmailEditor component, and when it finishes loading it hands you a Unlayer editor object through onReady. Everything you do afterwards goes through that object: loadDesign takes a design JSON object and loads it into the editor, saveDesign returns the design JSON in a callback, and exportHtml returns both the design HTML and JSON in a callback. All unlayer methods are available on emailEditorRef.current.editor.

That means the data flow is design JSON in, design JSON plus responsive HTML out. The JSON is what you persist; the HTML is what you send. The component exposes a small set of props around this: editorId for the container div, minHeight defaulting to 500px, onLoad when the instance is created, onReady when loading finishes, an options object passed to the Unlayer instance, and a style object for the container. The README points at the Unlayer docs for the full option list rather than reproducing it, which is the honest boundary of this repository: the configuration surface lives upstream.

Because the component is client-only and renders into the DOM, the published bundle includes the 'use client' directive. With the Next.js App Router the README states you can import it directly from a Client Component and do not need a next/dynamic workaround.

Installing react-email-editor and exporting your first template

Installation is a single npm command, as the README shows. The package requires React 16.8 or newer as a peer dependency and Node 18 or newer, per the engines field and the 2.0 upgrade notes.

npm install react-email-editor --save

The README's usage example wires the component to a ref and exports HTML from a button. Note that the ref type is EditorRef and the editor is reached through emailEditorRef.current?.editor, not through the ref directly.

import React, { useRef } from 'react';
import EmailEditor, { EditorRef, EmailEditorProps } from 'react-email-editor';

const App = () => {
  const emailEditorRef = useRef<EditorRef>(null);

  const exportHtml = () => {
    const unlayer = emailEditorRef.current?.editor;
    unlayer?.exportHtml((data) => {
      const { design, html } = data;
      console.log('exportHtml', html);
    });
  };

  return <EmailEditor ref={emailEditorRef} onReady={(unlayer) => {}} />;
};

Loading a saved template happens in onReady. The README comments show the pattern: obtain the design JSON by calling unlayer.loadDesign(callback) or unlayer.exportHtml(callback), then pass it back in.

const onReady: EmailEditorProps['onReady'] = (unlayer) => {
  // const templateJson = { DESIGN JSON GOES HERE };
  // unlayer.loadDesign(templateJson);
};

If you want to see the editor before writing any code, the README links a live demo at react-email-editor-demo.netlify.app, with source under demo/src in the repository. That demo is the fastest way to judge whether the default block set matches what your users expect.

Version 2.0 is where upgrades actually break

The component API did not change in 2.0, and the README says most apps can upgrade without code changes. The breakage is in packaging and runtime requirements. React 16.8 and Node 18 are now enforced at install time. Deep imports such as react-email-editor/dist/... are blocked by the exports map, so any import that reaches past the package root will fail. The published code is ES2019, and the README is explicit that if you support legacy browsers through an old toolchain that cannot parse ES2019, you should stay on 1.x or transpile node_modules.

There is one behavioural change worth noting because it is a fix rather than a break: editors are now destroyed on unmount, described in the README as a long-standing leak fix. If you had worked around that leak with your own teardown logic, the workaround is now redundant.

The practical upgrade check is therefore three questions. Does your build parse ES2019? Do you import only from the package root? Are you on React 16.8+ and Node 18+? A no to any of them means staying on 1.x, and the CHANGELOG is where the full list lives.

Where react-email-editor is the wrong choice

The most important limitation is ownership. The editor you embed is Unlayer's product. This repository is MIT licensed, but that licence covers the React wrapper, not the editor that renders in the iframe. The README's support section describes output tested against popular email clients and lists Gmail, Apple Mail, Outlook and Yahoo Mail, but it does not describe what happens when you need to change how a block renders. You configure the editor through options and use its methods; you do not fork its rendering.

Second, the package is a client-side component with a hosted dependency. There is no documented offline or air-gapped mode in the README, and no self-hosting instructions. If your deployment cannot reach Unlayer's servers at runtime, this is the wrong tool, regardless of how good the React wrapper is.

Third, the README does not document rollback, versioning policy for the embedded editor, or pricing tiers. Those answers are on unlayer.com and in the Unlayer docs, not here. Treat the repository as the integration layer and the vendor as the product. Teams that expect one npm dependency to be the whole system will be surprised at the boundary.

React Email and other JSX-first approaches

The obvious alternative is React Email, which people search for alongside this project. The difference is not quality, it is who does the editing. React Email is a JSX-first approach: templates are components you write, review and version in your codebase, and the output is rendered from that code. react-email-editor is a runtime visual editor: end users drag blocks, and your application stores design JSON and exports HTML.

That distinction decides the choice. If the people creating templates are developers, JSX components fit a pull request workflow and give you diffs. If the people creating templates are marketers or customers, a drag-and-drop surface is the requirement and JSX is a non-starter. There is no middle ground where you get both without maintaining two template systems.

A second comparison is with rolling your own editor. That is a real option and sometimes the right one, but the cost is not the drag-and-drop layer. It is the email-client compatibility work that the README's support table implies, and that work never finishes.

Licence, maintenance and the cost of staying current

The repository is MIT licensed, and package.json declares Node 18 or newer with React 16.8 or newer as a peer dependency. The only runtime dependency is @unlayer/types, which supplies the TypeScript types for the editor instance; the rest of the devDependencies are build and test tooling (tsup, vitest, prettier, TypeScript). That is a small dependency footprint for a component that fronts a large editor.

Maintenance is visible in the release cadence: v2.0.0 on 2026-07-06 and v2.1.2 on 2026-08-11, with the last push on 2026-09-10. The 2.0 notes show the maintainers are willing to make packaging-level breaking changes to modernize, which is good for the long run and annoying in the short run. Budget for a build-pipeline review at each major, not just an npm update.

The MIT licence on this wrapper does not settle the terms of the Unlayer editor itself. That is a separate commercial relationship, and the README does not describe it. Read the Unlayer terms before you plan a launch around this component; nothing in this repository grants rights to the hosted editor.

Editorial conclusion

Adopt react-email-editor if you need a visual email builder inside an existing React product and can accept that the editor itself is Unlayer's hosted product, not code you own. Skip it if you need an offline, self-contained editor, or if you cannot run React 16.8+ with Node 18+ and ES2019 output. Before committing, open the live demo, confirm your Unlayer plan covers the export and template features you rely on, and verify that your build pipeline parses ES2019, since that is the constraint most likely to force you back to 1.x.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. unlayer/react-email-editor on GitHub