Email Template Builder

Marketing and transactional emails are built differently from ordinary web pages, and that difference catches a lot of people off guard the first time they try to hand-code one. A regular webpage can use CSS classes, flexbox, external stylesheets, and whatever layout technique the framework of the day favors. HTML email cannot rely on any of that, because the rendering engines inside Gmail, Outlook, Apple Mail and dozens of other clients are wildly inconsistent, several of them (Outlook desktop especially, which still uses Microsoft Word's rendering engine for HTML email) don't support modern CSS at all, and most clients strip `<style>` blocks and external stylesheets outright as a spam and tracking countermeasure. The one layout approach that has reliably worked across nearly every client for over two decades is a `<table>`-based structure with every style declared inline, directly on each element — which is exactly what this tool generates. The block-based approach mirrors how most email marketing platforms — Mailchimp, Klaviyo, and similar tools — let non-developers assemble a template: pick a block type, fill in its fields, reorder as needed. Six block types cover the overwhelming majority of simple email layouts. A Heading (rendered as an inline-styled `<h1>` or `<h2>`) establishes a title or section break. A Paragraph carries body copy. A Button renders as an `<a>` tag styled to look like a button — a real button element doesn't exist in email-safe HTML, so a heavily-styled link is the standard technique, and it's also the only one guaranteed to remain clickable across clients that strip form elements entirely. An Image embeds a `<img>` pointing at a URL you supply; this tool deliberately does not host or upload images itself, since a functioning email needs its images hosted somewhere with a stable, long-lived URL, which is a hosting decision outside the scope of a browser-only tool. A Divider inserts a thin horizontal rule to separate sections visually. A Spacer inserts an empty, fixed-height row — the standard trick for controlling vertical whitespace in email, since `margin` and `padding` values are inconsistently honored by different clients but a table row's `height` almost always is. Reordering uses simple up/down buttons rather than drag-and-drop, deliberately: this project does not add npm dependencies, and every popular drag-and-drop library is a dependency. Swapping array indices on a button click accomplishes the same reordering with zero additional code weight and full keyboard accessibility, which drag-and-drop interfaces often lack. The outer content width is fixed at 600 pixels and is not user-editable. That number isn't arbitrary — 600px has been the de facto standard maximum width for HTML email for well over a decade, chosen because it comfortably fits inside the preview panes of virtually every desktop email client without a horizontal scrollbar, while still rendering reasonably on the narrower viewports of mobile mail apps. Templates built wider than roughly 600–650px routinely get clipped, horizontally scrolled, or auto-shrunk in ways that break careful layouts, so keeping the builder locked to a known-safe width removes an entire category of subtle rendering bugs before they can happen.