How to Create Email Templates That Convert

Email templates that convert share five traits: a single clear CTA, a hero that answers "why should I read this", a one-column mobile-first layout, preheader text that extends the subject line, and a body scannable enough to survive an eight-second skim. Gradients, animations, and clever copy are optional; those five are not.

Most templates I've audited fail on the basics rather than the flourishes. They break below 375px, they bury the call to action under a stock photo, or they compete with themselves by offering three things to click. None of that is a design problem. It's a decision problem.

What actually makes a template convert

A template converts when it moves a specific reader toward one specific action, quickly, on the device they happen to be holding. Pretty design helps. Pretty design without a clear next step is a PDF.

The hard part is restraint. When a founder sends me a template to review, I can usually guess the click rate within half a point by counting the buttons. Two buttons above the fold means average performance. One button, one promise, one obvious reason to click is where the lift lives. Every extra element is a tax on the primary action, and the tax compounds because each addition makes the next one feel reasonable.

One honest downside worth naming: good templates take longer to build than bad ones. A workable single-column layout with a hero and a CTA is maybe 30 minutes. A genuinely optimized, accessibility-checked, cross-client-tested HTML email is closer to half a day. Most teams under-invest here and then wonder why their sends underperform their industry benchmarks.

The six sections that carry the work

Every template that converts has the same six sections in roughly the same order. Miss one and you're pushing readers uphill for no reason.

Preheader text is the snippet Gmail, Apple Mail, and Outlook show next to the subject line. Skip it and the client grabs the first line of HTML, which is usually "View in browser"; that's a wasted slot in the most contested real estate you have. A good preheader reads like a second subject line rather than a repeat of the first. I run every one through the email preheader previewer before sending, because what you write and what the client displays are not always the same string.

Most hero images I see are stock photos with a headline stamped on top. That's a billboard. A converting hero answers one question in under two seconds: what's in this for me? A single line of text on a solid background will beat a 400kb image more often than designers like to admit, especially on a slow connection.

And if you've written "Learn More" on a button in the last six months, consider stopping. A call to action should say exactly what happens next: "Claim your free seat", "Read the 4-minute guide", "Start my 14-day trial". The verb does the work. Pairing that button with the right subject line matters too; the welcome subject lines and ecommerce subject lines collections are useful for seeing how the promise carries from inbox to button.

Structure it for scanning

Nielsen Norman Group has documented for two decades that people read screens in an F-pattern: across the top, down the left edge, pausing on headings, bolded text, and the first few words of each paragraph (Nielsen Norman Group on F-pattern reading). Inbox readers are, if anything, less patient than web readers; they didn't go looking for you.

I've stopped building multi-column email layouts entirely. Every two-column design I shipped between 2022 and 2024 underperformed its single-column version. Two columns only work if both get equal attention, and on a phone they collapse into a stack where the second column becomes a confused afterthought. One column also makes responsive design nearly free, because there's nothing left to rearrange.

Hierarchy should be obvious without squinting. I aim for a 28–32px H1, 20–22px H2, and 16px body copy at 1.5 line height. Bolding one or two phrases per section guides the eye; bolding twelve things gives the reader nothing to anchor on and reads as panic.

Design text-first and treat images as enhancement. Images break, get blocked, and load slowly on transit Wi-Fi. A template that's still legible with every image stripped out is a template that works everywhere.

Design for the phone first

You don't control the device, and a layout that fails below 375px fails silently. Nobody emails to tell you the button was off-screen; they just don't click.

A few rules I no longer break:

• Body container max-width of 600px, which degrades gracefully to any phone
• Minimum 44x44px tap targets on buttons
• 16px minimum body font, because iOS zooms anything smaller
• Line length of 50–75 characters on desktop, shorter on mobile
• No background images in layouts that break without them, since Outlook ignores many of them

MJML handles most of this automatically, which is why I default to it. It compiles a readable markup language down to the table-based HTML that email clients actually render (MJML documentation), and the MJML to HTML converter will turn a 40-line file into the 400-line output Outlook needs. Hand-rolling media queries gets you the same result for triple the work.

This is also the honest answer to the builder-versus-hand-code question. Start with MJML or a drag-and-drop builder that outputs clean HTML; hand-coding only pays off when you have a designer who knows the Outlook table quirks cold. On hero images, design at 1200x600 for retina, then compress below 200kb. Compressed JPEGs beat uncompressed PNGs for photographic content nearly every time, and SVG is lovely but needs a PNG fallback because client support is uneven.

Once it's built, preview it. The responsive email tester runs one template against a dozen viewport widths in a single pass, which is the fastest way to catch the "looks great on my MacBook, breaks on a Pixel" bug.

Test three ways before the first real send

Render testing comes first. Push every template through a service that spins up real clients and screenshots what they render; Litmus and Email on Acid both do this. A template that looks perfect in Chrome can and will break in Outlook on a locked-down corporate laptop.

Content testing is cheaper and people skip it anyway. Read the email aloud. It takes 90 seconds. If a sentence sounds like a pitch deck, rewrite it. If the CTA doesn't finish the thought the hero started, rewrite that. If you can't find the unsubscribe link in five seconds, the footer is too clever.

Then send it to yourself across three or four providers and check the boring things: whether the subject truncates in the preview pane, whether the preheader appears instead of "View in browser", whether images load, whether the button renders as a button rather than a blue underlined link, and whether dark mode inverts anything unintentionally.

That last one cost me. A dark-mode color swap turned black text on a dark grey button into invisible text on a dark grey button, and it rendered correctly on every desktop preview I ran; I simply hadn't flipped dark mode on the phone simulator. The client noticed before I did.

When you move from testing renders to testing performance, hold the line on sample size. Statistical significance at 95% confidence usually means somewhere north of a thousand opens per variant for a click rate test, and small lists won't hit that on one send. Aggregate three or four sends of the same template, or run the numbers through the A/B test calculator first. Declaring a winner at 200 opens is how templates end up optimized on noise.

Accessibility is the same work as conversion

Screen-reader users, low-vision users, and anyone reading in bright sunlight are all served by the same fundamentals that lift conversion for everyone else. WebAIM's guidance is the clearest starting point (WebAIM).

Four things to verify on every template: alt text on every image that carries meaning and alt="" on decorative ones, a semantic heading structure with one H1 and no skipped levels, at least 4.5:1 contrast for body copy, and a logical reading order once CSS is stripped, because screen readers often strip it.

The email accessibility checker flags all four, and it's the fastest pre-send check I run. Icons are a common contrast trap, so the email icon pack ships with a tested-contrast set.

The failures that repeat

Three mistakes account for most of the underperforming templates I review, and none of them are exotic.

The first is a subject and preheader that disagree. If the subject promises a discount and the preheader talks about a webinar, both feel dishonest before the reader has opened anything; the subject line guide covers pairing them properly.

The second is over-personalization. "Hey {{first_name|friend}}" rendering as "Hey friend" announces a broken merge field. Referencing plan tier, last action, or segment beats a shallow name-drop; email personalization goes deeper on that.

The third is a footer that's missing pieces. No physical address is a CAN-SPAM problem in the US; no visible unsubscribe is a GDPR problem in the EU. Both are trivially fixable and both get skipped in a rush.

One more for teams using AI: don't ship AI-generated copy without a human edit. The practical workflow is in the how to use AI email writing guide, but the short version is that AI drafts are starting points. An AI template you didn't read carefully will sound like an AI template, and readers notice faster than you'd hope.