React Email vs Maizzle: React components or Vue components for your emails?

The same job in each framework

React Email's manual setup page has you add an email:dev script, create emails/email.tsx and open localhost:3000 to watch it update. This is the template from that Manual Setup guide:

import { Button, Html, Head, Body } from "react-email";
import * as React from "react";

export default function Email() {
  return (
    <Html>
      <Head />
      <Body>
        <Button
          href="https://example.com"
          style={{ background: "#000", color: "#fff", padding: "12px 20px" }}
        >
          Click me
        </Button>
      </Body>
    </Html>
  );
}

Notice that styling here is an inline style object on the component. For Maizzle, a comparable verification email uses the component names its React Email migration guide maps one to one (Html, Head, Body, Container, Text, Button) and styles them with Tailwind classes. The structure below follows the documented component set:

<script setup>
  defineProps({ name: String })
</script>

<template>
  <Html>
    <Head />
    <Tailwind>
      <Body class="bg-white font-sans text-base text-gray-600">
        <Container class="max-w-lg">
          <Text class="text-2xl text-gray-950">Hi {{ name }}</Text>
          <Button href="https://example.com/verify" class="bg-blue-600 text-white">
            Verify email
          </Button>
        </Container>
      </Body>
    </Tailwind>
  </Html>
</template>

Two differences show up immediately. The Vue version declares its input with defineProps and prints it with a plain mustache, while the React version would take a typed props object and a JSX expression. And the Maizzle file puts Tailwind classes on every element, because the Tailwind wrapper is part of the template rather than something you bolt on later.

Tailwind is where they really differ

Email clients are fussy about CSS units and selectors, so how a framework treats Tailwind decides how many surprises you get. React Email's Tailwind component is a wrapper that takes a JavaScript config object. Its docs name the Tailwind version it uses (4.1.12) and tell you to apply pixelBasedPreset, because Tailwind's default rem units are not supported by some email clients and the preset bases sizes on 16px instead:

import { Tailwind, pixelBasedPreset, Button } from "react-email";

const Email = () => {
  return (
    <Tailwind
      config={{
        presets: [pixelBasedPreset],
        theme: {
          extend: {
            colors: {
              brand: "#007291",
            },
          },
        },
      }}
    >
      <Button
        href="https://example.com"
        className="bg-brand px-3 py-2 font-medium leading-4 text-white"
      >
        Click me
      </Button>
    </Tailwind>
  );
};

The same page lists known limitations, and they are worth reading before you commit to a design system. A context provider placed inside the Tailwind component will not reach its children through useContext, so the docs say to put the provider above it. The prose classes from the typography plugin are not supported, and neither is the space-* utility, because the component maps class names to inline styles and cannot resolve selectors more complex than a single class.

Maizzle takes a different route. Its migration guide says you pass the config to a slot as CSS, as in Tailwind 4, and that an official email config ships by default: a px scale instead of rem, HEX colours instead of oklch(), prose typography styles for HTML emails, and variants that target clients such as gmail: and ios:. After rendering, a transformer pipeline handles CSS inlining and unused-CSS removal. If your designers already maintain a shared Tailwind theme, check which framework can read it with the least translation: a JS config object suits a React codebase, a CSS-first config suits one built on Tailwind 4.

Getting HTML and plain text out

React Email's render utility converts a component to an HTML string, and a separate toPlainText converts that HTML into a text part. Content can be kept out of the text version by adding data-skip-in-text="true" to an element:

import { MyTemplate } from './email';
import { toPlainText, render } from 'react-email';

const html = await render(<MyTemplate />);
const text = toPlainText(html);

Maizzle exposes the same idea through its own render(), which per its migration guide runs the full pipeline (server-side rendering, CSS inlining, transformers, doctype) and returns html plus, optionally, plaintext. The call below is the shape shown in Maizzle's Resend deploy guide:

import { render } from '@maizzle/framework'

const { html, plaintext } = await render('emails/welcome.vue')

Where React Email uses an attribute to drop an element from the text version, Maizzle uses components: Plaintext renders content only in the text output and NotPlaintext everywhere except there. Both approaches work; the component form is easier to scan in a long template, and the attribute form is easier to add to an existing one.

Day-to-day differences worth knowing

Dev server

React Email's server is a preview of rendered components. Maizzle's is described as having live preview and hot reloading, device resizing, compatibility checks with jump-to-editor, dark mode emulation, quick search and even test email sending. If your team wants lint-style warnings while typing instead of finding problems in a later preview run, that list favours Maizzle. If you only want to see the email update as you edit TSX, both are enough.

Components you will miss or gain

Maizzle's guide lists eleven components with no React Email equivalent: Layout, Outlook, NotOutlook, OutlookBg, Spacer, NoWidows, Raw, WithUrl, Plaintext, NotPlaintext and QrCode. WithUrl in particular adds base URLs and tracking query parameters to links, which saves a helper function in every project. React Email's own set covers Html, Head, Body, Container, Section, Row, Column, Heading, Text, Button, Link, Image, Hr, Font, Preview, Markdown, CodeBlock, CodeInline and Tailwind, and its docs navigation lists an Editor section beside the primitives, which is worth a look if non-developers need to touch templates.

What the stack costs around two free frameworks

Frameworks cost nothing, but email still has two bills: delivery and previews. The sending side is where your volume shows up, so here are three volumes read off each vendor's pricing page (read October 7, 2026).

Both senders price large volumes from a slider rather than a formula: Resend's showed Pro at $35 for 100,000 and Scale at $160 for 200,000, and Postmark's showed Basic at $15, $55 and $115 at 10,000, 50,000 and 125,000. Do not extend a plan price with the per-1,000 overage rate on either card. SendGrid's Email API pricing shows an Essentials plan at $19.95 and Pro at $89.95 in its plan selector.

The free Resend tier stops at 100 emails a day, so a launch day with a burst of password resets can hit the cap even when the monthly total is small. Either framework works with each of these senders, since React Email documents a Resend integration, among others, and Maizzle documents a deploy recipe for each of them. Because Resend and React Email come from the same company, people assume they must be paired, yet the React Email docs list Nodemailer, Mailgun, SendGrid, Postmark, AWS SES and several others next to Resend.

Previews cost more than you expect

Neither framework screenshots your email in real clients. Maizzle's dev server runs compatibility checks and says to test in real clients before sending; React Email says its components were tested in popular clients, which says nothing about the layouts you build from them. For screenshots you need a preview service. On its pricing page Email on Acid lists Basic at $99 a month for 1,000 previews and Premium at $199 for 2,000, with overage at $0.15 per preview, and notes that subscriptions are transitioning to Mailgun Inspect. If a full run covers 50 clients and each client counts as one preview, Basic funds 20 runs. Thirty runs would use 1,500 previews: $99 + 500 x $0.15 = $174, still cheaper than Premium's $199 until roughly 1,667 previews. Whichever framework gives you the shorter edit loop spends fewer of these previews, and our Litmus vs Email on Acid page covers the testing side in detail.

Choose React Email if…

• The application is React or Next.js and the same engineers own the product and its transactional email.
• You want templates typed with props, in the same repository and lint rules as the rest of the app.
• You send through Resend or any of the other services in the docs' integration list and want the shortest path from component to API call.
• You are happy to do without prose and space-* utilities and design around the documented Tailwind limits.

Choose Maizzle if…

• Your front end is Vue, Nuxt, Laravel, SvelteKit or Astro and you would rather not add React to a project that has none.
• You want CSS inlining, unused-CSS removal and Outlook helpers as part of the build rather than assembled yourself.
• You use Tailwind 4 and want email-safe defaults (px scale, HEX colours, client variants) without writing a preset.
• You need to branch content for plain text or Outlook inside the template, using components built for that.

Switching between them

React Email to Maizzle is the documented direction. Maizzle's guide gives a component map covering nineteen React Email components, keeps most names, and renames only Preview, which becomes Preheader. The work is in three places: converting JSX to Vue templates, moving the Tailwind config into CSS, and swapping the render() import in your sending code, since the guide says sending itself does not change. Start with the plainest template, such as a password reset, and compare previews before moving the rest. Going from Maizzle to React Email has no equivalent guide, and any template using Outlook, OutlookBg or WithUrl needs those pieces rebuilt by hand.

If you are weighing a markup language instead of a component framework, see MJML vs React Email and Maizzle vs MJML. For the CSS limits behind every choice on this page, read CSS in email and the client compatibility guide, and for the sender you will pair with either framework compare Resend vs Postmark.