Why HTML emails break in Outlook and Gmail, the table and inline CSS rules email still forces on you, and how to build templates that render everywhere.
Email clients render HTML using rules that web browsers abandoned two decades ago. Outlook on Windows uses Microsoft Word's rendering engine. Gmail strips out <style> blocks in some contexts. A layout that looks perfect in your browser can arrive as a stack of misaligned blocks in someone's inbox. An email template builder handles those constraints for you but knowing what they are explains why the output looks the way it does. Try the free Email Template Builder → The Rules Email Forces on You Tables for layout — genuinely. This is the one case where table-based layout is still correct. Flexbox and Grid have unreliable support across email clients, so nested tables remain the only structure that renders consistently everywhere. Inline CSS. Styles belong in style attributes on individual elements, not in a <style> block. Several clients strip embedded stylesheets entirely, and a template relying on them arrives unstyled. No JavaScript. Blocked universally, for good security reasons. Anything interactive has to happen after the reader clicks through to a web page. Fixed width, around 600px. The long-standing safe width. Wider templates get clipped in narrow preview panes. Web-safe fonts with fallbacks. Custom web fonts fail in many clients. Specify a full font stack ending in a generic family, and design assuming the fallback is what most readers will see. Absolute image URLs, and images off by default. Images must be hosted somewhere public and referenced by full URL. Many clients block them until the reader opts in — so the email must still make sense with every image missing. Always write meaningful alt text. Background images are unreliable. Outlook in particular ignores CSS background images. Use solid background colours for anything structural. Structure That Survives A template that renders consistently generally follows this shape: Preheader text - the short line shown after the subject in inbox previews. Left unset, clients pull whatever text comes first, which is often "View in browser." Header - logo, kept simple, on a solid background Body - single column wherever possible; multi-column layouts are the first thing to break Call to action - a bulletproof button (see below) Footer - unsubscribe link, physical address, contact details Single column is the safest choice. It renders identically everywhere and needs no responsive handling to work on phones, where most email is now read. Bulletproof Buttons A CTA styled as a <div> with a background colour and padding will render as plain text in Outlook. The reliable approach uses a table cell as the button: html <table cellpadding="0" cellspacing="0" border="0"> <tr> <td bgcolor="#0066cc" style="border-radius:4px; padding:12px 24px;"> <a href="https://example.com" style="color:#ffffff; text-decoration:none; font-family:Arial,sans-serif; font-size:16px; display:inline-block;"> Get Started </a> </td> </tr> </table> The background colour sits on the table cell rather than the link, which is what makes it survive Outlook. Note bgcolor as an HTML attribute alongside the CSS the belt-and-braces approach email requires. Testing Before You Send The clients that matter most, in rough order of how much trouble they cause: Outlook (Windows desktop) - the Word rendering engine; if it works here, it works nearly everywhere Gmail (web and app) - strips some CSS, handles others inconsistently Apple Mail / iOS Mail - most standards-compliant, least trouble Outlook.com - different engine from desktop Outlook, tested separately Minimum viable test: send the email to yourself and open it in Gmail on a phone and Outlook on a desktop. Those two cover the majority of real-world readers and catch most breakage. Also check with images blocked, and check the dark-mode rendering — several clients invert colours automatically, which can turn a dark logo invisible against a newly dark background. Practical Details Worth Getting Right File size under 102 KB. Gmail clips messages beyond that, hiding the end behind a "View entire message" link including your unsubscribe footer. Alt text on every image. With images blocked, alt text is the email. Real text, not text in images. Images of text are unreadable when blocked, invisible to screen readers, and look poor on high-density displays. Working unsubscribe link. Legally required in most jurisdictions, and its absence drives spam complaints. Physical postal address in the footer. Required under CAN-SPAM and equivalent regulations. Frequently Asked Questions Why do I have to use tables in HTML email? Email clients Outlook on Windows especially, which renders using Microsoft Word's engine have unreliable support for modern CSS layout like Flexbox and Grid. Nested tables are the only layout method that renders consistently across all major clients. Does CSS need to be inline in HTML emails? Yes, for anything critical. Several clients strip <style> blocks, so styles applied there can disappear entirely. Inline style attributes on individual elements are the reliable appr