Get Started

Why HTML Emails Still Use Tables for Layout

Published

A technique the web left behind

If you learned web development any time in the last fifteen years, you were taught one rule early: don’t use tables for layout. Tables are for tabular data; layout belongs to CSS — flexbox, grid, and float. Using <table> to position content is considered a relic of the 1990s.

And yet, open the source of almost any email from a major brand and you’ll find it: nested <table> elements, <td> cells doing the work of columns, and inline styles everywhere. Email development didn’t get the memo — on purpose. In email, table-based layout isn’t a bad habit. It’s the only reliable option.

The reason: email clients aren’t browsers

A web page is rendered by a browser, and modern browsers (Chrome, Safari, Firefox, Edge) largely agree on how CSS should behave. An email is rendered by an email client, and email clients are a completely different, far less consistent world. (For the full breakdown, see Why Outlook, Gmail, and Apple Mail Render Differently.)

The single biggest reason tables persist is desktop Outlook. For versions spanning 2007 to 2021 — still widely used in corporate environments — Outlook on Windows rendered HTML email using the Microsoft Word rendering engine, not a browser. Word’s engine has no meaningful support for the CSS layout tools the web relies on:

  • float is unreliable or ignored
  • flexbox and grid don’t exist
  • max-width and min-width are ignored
  • margin behaves inconsistently
  • position is not supported

Ask Word to arrange two columns side by side using display: flex and it will simply stack them or ignore the styles. The one layout primitive Word does understand reliably is the <table>. Cells sit next to each other, widths are respected, and the structure holds. So to get predictable columns in Outlook, you build them as table cells.

What table-based email layout looks like

Instead of semantic containers, a table email nests structure like this:

  • An outer <table> centers the email and sets its width.
  • Inside, more tables create rows.
  • <td> cells act as columns, sitting side by side.
  • Spacing comes from cell padding, spacer rows, or transparent spacer images — not margin.

A layout that would be a few lines of flex on the web becomes dozens of lines of nested tables in email. It’s verbose, it’s fragile, and a single misplaced tag can break the whole structure in one client while looking fine in another.

Why not just use div and modern CSS?

You can — and in clients like Apple Mail and the new Chromium-based Outlook, a div-based layout renders beautifully. The problem is coverage. The moment a meaningful slice of your audience opens the email in classic Outlook, a div-and-flex layout falls apart, while everyone else sees it fine. Email developers don’t get to choose their readers’ clients, so they design for the lowest common denominator. Tables are that denominator.

Some teams do ship “modern” div-based emails when they know their audience uses well-behaved clients — but for broad-audience marketing and transactional email, tables remain the safe default.

Web page (browser)HTML email (email client)
Layout methodflexbox, grid, floatNested <table> / <td>
Spacingmargin, gapCell padding, spacer rows
CSS locationExternal or <style>Inlined on each element
Lowest common denominatorModern browsersOutlook (Word engine)
ResponsiveNative, easyMedia queries + stacking, fragile

The maintenance cost of hand-coding tables

Table layouts don’t just look dated — they’re genuinely hard to work with:

  • They’re verbose. Small designs balloon into hundreds of lines of markup.
  • They’re brittle. Deeply nested tables are easy to break and hard to debug.
  • They fight responsiveness. Making table columns stack on mobile requires careful media queries that some clients ignore.
  • They require CSS inlining. Because several clients strip <style>, every style has to move inline. See CSS Inlining in Email.

Maintaining this by hand across a library of emails is slow and error-prone. This is exactly the problem that abstraction layers were built to solve.

How MJML and Temway let you skip the tables

MJML (Mailjet Markup Language) is an open-source language designed to hide all of this. You write clean, semantic components — <mj-section>, <mj-column>, <mj-text>, <mj-button> — and MJML compiles them into the nested, inline-styled, table-based HTML that email clients need, complete with Outlook conditional comments and responsive stacking. (For a deeper introduction, read What Is MJML?.)

Temway takes it one step further: you don’t write MJML either. It’s a visual, drag-and-drop builder that renders every design through an MJML engine. You compose with blocks — Sections, Rows, and Columns — and Temway produces the table-based, cross-client-safe HTML on export. The tables are still there in the output, because email clients still need them. You just never have to write or maintain them.

Where to go next