Back to Blog

HTML Email Design: Best Practices Guide

The complete HTML email design guide — responsive layouts, Outlook compatibility, typography, images, and testing. With copy-paste templates.

HTML email design best practices guide

Posted by

HTML email design sits in a frustrating middle ground: complex enough to require real technical knowledge, but widely misunderstood because most web development rules don't apply. CSS Grid doesn't work. Flexbox doesn't work. External stylesheets get stripped. Background images get blocked. And Outlook — still used by a significant share of corporate email readers — renders HTML using Microsoft Word's layout engine.

This guide covers what actually works: the layout patterns, typography rules, image handling, and testing steps that produce reliable emails across Gmail, Outlook, and Apple Mail. It's written for developers and marketers who want to understand why email HTML is different — and how to get it right the first time.

Layout and Structure

Use table-based layouts

The single most important rule in HTML email design: use <table> elements for layout, not <div>. This is not a preference — it's a compatibility requirement. Outlook uses the Word rendering engine for HTML email, which has limited support for CSS layout properties. Tables are the only layout method that works reliably across all major email clients.

Structure your email as a wrapper table (full width), a content table (600px centered), and inner tables for each section. Nested tables are normal and expected in email HTML.

600px maximum width

Set your content container to a maximum of 600px wide. This is the de facto standard for email — it fits comfortably in the preview pane on desktop email clients and scales down well on mobile. Going wider risks horizontal scrolling in some clients.

Set the outer wrapper table to width="100%" and the inner content table to width="600" with max-width: 600px in the style attribute. This combination handles both fixed-width desktop views and fluid mobile rendering.

Use inline CSS — no external stylesheets

Many email clients strip <link> tags and <style> blocks from the <head>. Gmail strips <style> in some contexts. The safe approach: write all styles inline using the style attribute on each element.

This means writing style="color: #333333; font-size: 16px; line-height: 1.6;" on every <p> tag. It's verbose but it's the only reliably safe approach. Every template in the EmailBits library uses inline styles throughout.

Single-column layouts are safest

Multi-column layouts (two- or three-column grids) require careful handling on mobile. A two-column layout that looks great on desktop can collapse or overflow on a small screen. If you need multi-column sections, use a responsive approach with@media queries — keeping in mind that not all email clients support them (Outlook does not).

For the safest cross-client experience, use single-column layouts with feature callout blocks stacked vertically. This renders correctly in every client without media query support.

Responsive Email Design

Over 50% of emails are opened on mobile devices. A non-responsive email on mobile either forces the reader to zoom in and scroll horizontally, or the email client scales it down to an unreadable size.

Use media queries for clients that support them

Gmail (web, Android), Apple Mail, and most modern email clients support @media queries. Outlook does not. The standard approach: write a desktop-first layout with tables, then use media queries to adjust font sizes, stack columns, and increase tap target sizes on mobile.

Add a <style> block in the <head> for media queries — even though Gmail may strip it in some contexts, it will be applied in most. This is a progressive enhancement: the email looks good without it and better with it.

Set images to max-width: 100%

Add style="max-width: 100%; height: auto;" to all images. This prevents images from overflowing their container on narrow screens. Pair it with explicit width and height attributes on the <img> tag to maintain the correct aspect ratio when images are blocked.

Minimum 14px font size on mobile

iOS Mail auto-scales text smaller than 13px up to 13px, which can break your layout. Set body copy to at least 14–16px and headings to at least 22px. Use media queries to increase font sizes further on mobile if your desktop sizes are smaller than this baseline.

Typography

Use web-safe fonts

Custom web fonts (Google Fonts, Adobe Fonts) are supported in Apple Mail and a few other clients, but not in Gmail or Outlook. If you use a custom font, always specify a web-safe fallback stack: font-family: 'Your Font', Arial, Helvetica, sans-serif;

Web-safe fonts that render consistently across all clients: Arial, Helvetica, Georgia, Times New Roman, Trebuchet MS, Verdana. For most email use cases, Arial or Helvetica is the safest default.

Set explicit line-height

Email clients vary in their default line-height. Set it explicitly on every text element: line-height: 1.6 for body copy, line-height: 1.3 for headings. This prevents cramped or inconsistent text rendering across clients.

Use dark text on light backgrounds

Dark mode support in email clients is inconsistent and difficult to control. The safest approach: use dark text (at least #333333) on white or very light backgrounds. Avoid light-colored text on dark backgrounds for body copy — in clients that force light mode, this text can become unreadable.

Images

Always include alt text

A significant percentage of email clients block images by default — Outlook and corporate email environments are common examples. Every <img> tag needs meaningful alt text so readers understand the content even when images are blocked. For decorative images, use an empty alt attribute: alt="".

Avoid background images

CSS background images (background-image) are blocked in many email clients, most notably Outlook. If your layout depends on a background image for readability — for example, white text on a photo — it will fail. Use <img> tags for content images and solid background colors (via bgcolor attribute on table cells) instead of image backgrounds.

Host images on a reliable CDN

Images in emails are loaded from external URLs at the time of open, not embedded in the email. Use a reliable CDN or image hosting service. Avoid relative paths (they don't work) and localhost URLs (obviously broken in production). Many ESPs offer hosted image storage — use it, or host on your own CDN.

Specify exact width and height attributes

Add explicit width and height attributes to all images. When images are blocked, the email client uses these values to reserve space — preventing layout collapse. The alt text then appears in a box of the correct size rather than a collapsed zero-height space.

CTAs and Buttons

Use table-based bulletproof buttons

CSS-only buttons (<a> with padding and background-color) look correct in most clients but fail in Outlook, which ignores padding on inline elements. The solution: a table-based "bulletproof button" — a <table> with a single cell containing the link, with background-color and padding set on the <td>.

This approach renders as a styled button in every major client, including all versions of Outlook.

Minimum 44px tap target height

Apple's Human Interface Guidelines recommend a minimum tap target size of 44×44px. Set your button padding so the clickable area reaches at least 44px tall on mobile. A common safe value: padding: 14px 28px with a 16–18px font size.

One primary CTA per email

Emails with multiple CTAs see lower click-through rates than those with a single, clear action. If your email needs secondary links (social icons, footer links, "view in browser"), keep them visually subordinate to the primary CTA — smaller, less prominent, below the fold.

Common Mistakes to Avoid

  • Using CSS Grid or Flexbox for layout. Neither works in Outlook. Use tables.
  • Relying on external stylesheets. Gmail strips <link> tags. Use inline styles.
  • Using background images for hero sections. They're blocked in Outlook. Use a solid color or a stacked <img> element.
  • Forgetting alt text. When images are blocked, alt text is the only thing the reader sees in that space.
  • Small touch targets. Buttons under 44px tall are hard to tap accurately on mobile.
  • Not testing in Outlook. Outlook has the most divergent rendering behavior. If you only test in Gmail and Apple Mail, you'll miss Outlook failures that affect a significant share of corporate readers.
  • Using JavaScript or forms. Email clients strip both. Any interactivity in email must rely on links, not scripts.

Testing Checklist Before Sending

Before sending any HTML email, run through this checklist:

  • Preview in Gmail (web), Gmail (mobile), Outlook 2019+, and Apple Mail.
  • Disable images and check that the layout holds and alt text is meaningful.
  • Check on a physical mobile device — not just a browser resize.
  • Verify all links work and point to the correct URLs.
  • Check that CTA buttons render correctly (no flat/unstyled links).
  • Confirm the plain-text version exists and makes sense.
  • Run through a spam filter checker if your email has significant promotional content.

Tools like Litmus and Email on Acid provide automated rendering previews across 60+ clients. For lower-volume sending, the free tiers of these tools or manual test sends to personal accounts across clients cover the major failure modes.

Getting a Solid Starting Point

The fastest way to avoid the most common HTML email mistakes is to start from a template that already handles them. EmailBits has 600+ free HTML email templates — every one uses table-based layouts, inline CSS, and proper image attributes. Copy the HTML from any template and you get a cross-client-compatible base to work from, rather than debugging layout issues from a blank file.

If you need something more specific, the AI email generator produces a complete template from a description — including inline styles, responsive structure, and a bulletproof CTA button — in under two minutes.

Frequently Asked Questions

Why don't modern CSS layout techniques work in email?

Email clients use a range of rendering engines — some outdated, some deliberately restricted for security. Outlook uses the Word rendering engine, which has no support for Flexbox or Grid. Gmail strips styles from the <head> in some contexts. Email HTML support is frozen roughly at 2007 web standards for the clients that matter most.

Do I need to support dark mode in email?

Dark mode support in email clients is inconsistent and hard to control. Apple Mail and Outlook support prefers-color-scheme media queries, but Gmail does not. The safest baseline: ensure your email is readable in both light and dark contexts by using dark text on white backgrounds and avoiding very low-contrast color combinations.

Should I include a plain-text version?

Yes. Most ESPs send a multipart email (HTML + plain text) by default. The plain-text version is used by screen readers, some older clients, and some spam filters. Write a plain-text version that communicates the same message as the HTML — don't leave it empty or auto-generated.

What's the safest maximum email file size?

Keep the HTML file under 102KB. Gmail clips emails larger than 102KB, showing a "[Message clipped]" banner with a link to view the full email. This significantly reduces click-through rates. Keep images external (hosted on a CDN, not embedded as base64) and keep your HTML structure lean.

Can I use emoji in email subject lines?

Emoji in subject lines are widely supported and can improve open rates in some contexts. Use them sparingly — one or two at most — and test how they render in your target clients. Some older Outlook versions and corporate email environments display emoji as placeholder characters.