Mastering HTML email tables for layout

Quick answer: HTML email tables are nested <table> elements used to build the structure of an email – the container, the columns, the spacing – because email clients (especially the Word-based engine inside classic Outlook) still don’t reliably support modern CSS layout like Flexbox or Grid. In 2026 they remain the most dependable way to get a layout that holds together across every major client, even as the new Chromium-based Outlook slowly rolls out and Microsoft’s own retirement timeline keeps slipping further into the future.

There’s a particular kind of message every email developer dreads, and it almost always arrives in the evening, after the email’s already gone out. It’s a screenshot. The layout that looked flawless in Gmail and flawless on a phone has, in one specific inbox, completely come apart – the hero image blown out to twice its width, the columns refusing to sit side by side, the “register now” button relocated somewhere off the edge of the screen. The inbox is, of course, Outlook. It’s basically always Outlook. And the fix, almost every time, comes back to the same thing: HTML email tables, either used badly or skipped where they were doing the actual structural work. That’s what this whole guide is about.

This is the conversation we’re going to have. HTML email tables are the reason that email could have held together, and the absence of proper table structure is the reason it didn’t. I’ve been building emails for a living for years, and I can tell you that almost every “why does my email look broken” panic traces back to one of two things: somebody trusted a div where they should have used a table, or somebody used a table but skipped the parts that actually do the work. So let’s fix both.

This is the long version. The genuinely useful version, not the “here is a <tr> tag, here is a <td> tag, congratulations you know HTML” version that the first page of Google is stuffed with. We’re going to cover what these tables are and why we’re still building emails like it’s 2009, the current Outlook situation (which shifted again earlier this year and a lot of the internet still hasn’t caught up), how to actually build the patterns that survive contact with real inboxes, the ghost table trick that separates people who know email from people who Googled email, accessibility done properly, where this whole approach falls apart, which email service providers will quietly ruin your work, how to test it without going broke, and where the technique is headed over the next five years. There’s an FAQ at the bottom for the skimmers.

Grab a coffee. This one’s a slog, in the good way.

What are HTML email tables, and why are we still doing this in 2026?

Let me give you the clean definition first, because somebody’s going to paste it into a client brief and I’d rather they pasted a good one.

HTML email tables are <table> elements used to lay out the visual structure of an email – the outer container that holds everything, the columns that sit side by side, the cells that control padding and spacing. You nest them inside each other to build the shape of the email. It’s the same <table> tag you’d use to show a spreadsheet of data on a web page, except here we’re abusing it for layout, which is a thing the web world abandoned around 2010 and email never could.

And that “never could” is the whole story.

Outlook on Windows issue

Here’s the thing nobody outside email development quite believes when you tell them: the desktop version of Outlook on Windows renders HTML using Microsoft Word. Not a browser. Word. The word processor. And not even a recent version of it – it’s been running on the Word 2007 rendering engine for the better part of two decades. So when you send an email to someone using classic Outlook, your carefully coded layout gets handed to a piece of technology that is old enough to legally drink, drive, and vote, and whose original job was making sure your résumé didn’t have a typo. It has no idea what Flexbox is. CSS Grid? Forget it. float behaves unpredictably. display: inline-block is a coin flip. margin: 0 auto to center something? It’ll laugh at you.

The one layout tool that this ancient engine handles consistently – the one thing it actually understands – is the table. Nested <table> elements with explicit pixel widths. It’s verbose, it’s ugly, it’s the kind of markup that makes a modern front-end developer physically recoil. But it works. Everywhere. That’s the entire pitch.

If I had to put it on a sticky note: HTML email tables exist because Outlook exists, and Outlook decided in 2007 to render your emails with a word processor.

Now, there’s a distinction worth getting straight early, because it comes back later when we talk about accessibility and it trips people up constantly.

• Layout tables – tables you’re using to position things. The container, the columns. These are a hack. They carry no real meaning; they’re scaffolding.
• Data tables – tables showing actual tabular data. A pricing comparison. An order summary with quantities and line items. These are tables doing the job tables were invented for.

You handle these two completely differently when it comes to screen readers, and we’ll get to that. For now just file it away: not every <table> in your email means the same thing, even though they look identical in the code.

The state of HTML email tables in 2026 – and why the timeline everyone quotes is wrong

This is the section I actually care about, because it’s where most of the content on this topic is now flat-out wrong, including stuff published this year.

You’ve probably read that classic Outlook is dying in October 2026. Or that the new Outlook became the default in April 2026 and the old one is on its way out. You’ve maybe read that the Word rendering engine – the source of all our suffering – is finally getting retired and we can all go back to writing normal CSS soon.

Most of that is outdated. Some of it was never quite right. Here’s what’s actually true as of right now.

What changed (and it changed quietly)

Microsoft moved the goalposts. Again. The “opt-out” phase – the point where the new Outlook becomes the default experience and you have to actively switch back to classic if you want it – was originally slated for April 2026. Earlier this year Microsoft pushed it back to March 2027. The “cutover” phase, where classic Outlook genuinely goes away and you can’t switch back, is now no earlier than March 2028, and managed enterprise customers get at least 12 months of notice before it hits them.

And the headline number, the one that matters most for anyone building HTML email tables today: classic Outlook for Windows will be supported – with security updates and compatibility maintenance – through at least 2029 for Microsoft 365 subscribers and anyone on a perpetual license like Office 2024 or Office LTSC.

So when you see “classic Outlook dies October 2026,” understand that date is either confused or stale. (The October 2026 date that floats around is mostly tangled up with the retirement of Exchange Web Services in Exchange Online, which is a server-side thing about how integrations talk to mailboxes, not about how your email renders. Different problem entirely. People conflate them.)

Here’s the timeline in plain terms:

And the old versions aren’t going anywhere either

There’s a separate wrinkle. Outlook 2016 and Outlook 2019 both hit end of support entirely on October 14, 2025 – mainstream support for those builds actually lapsed years earlier, so October 2025 was the final cutoff for security updates too. No more updates of any kind. But – and anyone who’s worked with corporate IT already knows where this is going – the people running those builds are not going to upgrade just because a support page told them to. Change management at a bank or a hospital or a government department moves at the speed of geology. Those 2016 and 2019 installs will be opening your emails for years, just without security patches, which is its own special horror but not our problem today.

So what does this mean for the new Outlook itself?

The new Outlook for Windows is genuinely different. It runs on a Chromium-based engine (Edge WebView2), basically the same rendering you get in Outlook.com and the web version. And for us, that’s mostly great news:

• CSS support is dramatically better. Flexbox works.
• Background images render properly.
• Padding and margin on a plain <div> behave the way they should.
• Media queries are fully supported.
• VML and those MSO conditional comments we’ll talk about? The new Outlook just ignores them.

After nearly twenty years of the Word engine making everyone’s life harder than it needed to be, the new Outlook is finally a normal web rendering target. Almost.

Because there’s a catch. There’s always a catch. The new Outlook has a post-processing layer that rewrites your styles after the email loads. The famous one is the border-radius bug – you set border-radius: 20px 20px 0 0 to round just the top corners of something, and the new Outlook silently flattens it to border-radius: 20px on all four. So “Chromium-based” does not mean “behaves identically to Chrome.” Test it. Always test it.

The bottom line for tables

Put all of that together and the conclusion writes itself: HTML email tables are not going anywhere on any timeline that affects an email you’re sending this quarter, or next quarter, or honestly for the next several years. If your audience has any meaningful slice of corporate or B2B subscribers, classic Outlook is in those inboxes through 2028, 2029, and probably beyond for the most conservative organizations. The Word engine is dying the way a glacier dies. Slowly, and not on the schedule anyone wants.

(If you want the deep dive on responsive techniques that survive even when the table approach gets stretched thin, I’ve written separately about fluid hybrid email design, which builds directly on everything here. This article is the foundation; that one’s the advanced application.)

Tables vs divs – let’s answer this so we can move on

I’m including this section reluctantly, because the “tables versus divs” debate is the most tired argument in email development, and it gets rehashed roughly every eleven minutes by someone discovering the topic for the first time. But people search for it, and there’s a real answer, so here it is, fast.

Can you build emails with divs instead of tables? In 2026, divs are supported in essentially 100% of email clients – except classic Outlook on Windows. Which, as we just spent a thousand words establishing, is exactly the client you can’t afford to ignore. So the honest answer is:

• Divs work great everywhere modern.
• Divs fall apart in the one place where falling apart costs you a B2B sale.
• Therefore you can’t just use divs, you use a hybrid.

The practitioner consensus – and I’m with the camp on this – is tables as the structural backbone, divs and semantic tags layered on top only where you’ve personally confirmed the client support is solid. Tables for the load-bearing walls. Divs for the decorative trim.

Here’s the comparison, because a table comparing whether you should use tables is the kind of joke email developers find funny and nobody else does:

The whole debate, when you strip it down, is mostly people who don’t send to corporate lists arguing with people who do. If your entire audience is on Apple Mail and Gmail mobile, go nuts with divs. The moment one VP forwards your email into Outlook desktop, you’ll wish you’d used HTML email tables for the structure. I’ve watched it happen enough times that I just default to the table backbone now and don’t think about it.

Moving on.

How to build HTML email tables – the patterns that actually matter

Right. The technical section. Code blocks ahead. I’m going to walk through the structure for a single-column email with a two-column feature block, because that shape covers maybe 70% of the production emails I build, and once you understand it the rest is just repetition.

A quick word on the basics so I don’t have to keep stopping. A table is <table>. A row is <tr>. A cell is <td>. You put content in cells, cells live in rows, rows live in tables, and tables nest inside each other’s cells to build complexity. That’s the entire vocabulary. If you needed that paragraph, bookmark this and go build something small first, then come back.

The 600px container – and why everyone uses 600

Every email starts with the same skeleton: a full-width outer table acting as a safety net, and an inner table that holds your actual content, capped at a fixed width.

<table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">
  <tr>
    <td align="center">
      <table role="presentation" width="100%" style="max-width: 600px;" cellpadding="0" cellspacing="0" border="0">
        <!-- your email lives here -->
      </table>
    </td>
  </tr>
</table>

The outer table at 100% is there to catch the email no matter what weird container some webmail client drops it into. The inner table is the actual email – it’ll stretch to 100% on a phone and cap out at 600px on anything wider.

Why 600? It’s convention, not law. It traces back to old Outlook reading-pane widths and has stuck around because it works – it’s wide enough to be useful, narrow enough to fit comfortably on most screens without horizontal scrolling, and it gives mobile a sensible amount to work with. You’ll see 640px sometimes. Some people push to 680px now that screens are bigger. Six hundred is the safe default and I’d stick with it unless you have a specific reason not to.

Notice the role="presentation" on both tables. Put it on every layout table from the very first one you write – it’s an accessibility requirement and I’ll explain it properly in a bit, but build the habit now so you’re not retrofitting it later.

Nesting tables without losing your mind

The mental model that makes nested HTML email tables click: tables are blocks. Lego bricks. You’ve got a container brick, and inside it you stack section bricks (your header, your hero, your body, your footer), and inside some of those you put column bricks. Each brick is self-contained. You can pick one up and move it somewhere else and it brings its own structure with it.

Build modularly. One table per logical section. It’s tempting to cram everything into one giant table to save markup, and then six weeks later the client wants to swap two sections and you’re untangling a <td> nightmare at midnight. Don’t do that to future you.

Here’s the warning that’s worth more than the rest of this section combined: in Outlook, one missing closing tag eats the entire campaign. A forgotten </td> or </table> won’t necessarily break anything in your Chrome preview – the browser is forgiving, it patches your sloppy markup silently. Word-engine Outlook is not forgiving. It’ll render the rest of your email as a smear of overlapping garbage, and you won’t know why, because it looked fine when you checked. Close every tag. Indent properly so you can see the structure. I’m not being precious about code style here, I’m trying to save your launch.

A two-column block that stacks on mobile

This is the pattern people actually want when they ask about HTML email tables. Two columns side by side on desktop, stacking to a single column on a phone. Here’s the table-backbone version:

<table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">
  <tr>
    <td width="300" valign="top">
      <!-- left column: speaker photo -->
    </td>
    <td width="300" valign="top">
      <!-- right column: bio + button -->
    </td>
  </tr>
</table>

That gives you a solid two-column layout in every client including Outlook. The catch is that a pure table approach like this doesn’t stack on mobile by itself – the cells stay side by side and get crushed. To get clean stacking you either layer media queries on top (great for clients that support them) or move to the hybrid div-inside-ghost-table pattern, which gets the stacking for free without media queries. That hybrid technique is its own whole topic and I’ve covered it in depth elsewhere; for most two-column blocks, the table backbone plus a media query that switches the cells to display: block; width: 100% on small screens does the job fine.

Padding, gutters, and the trap that gets literally everyone

Okay, this one. This is the single most common mistake I see in code reviews, and I made it myself for an embarrassingly long time when I started.

Classic Outlook ignores padding declared on a <div>. You write <div style="padding: 20px">, it looks perfect in Chrome, perfect in Gmail, perfect on your phone, and then in Outlook your content is jammed flush against the edges with no breathing room and you cannot for the life of you figure out why, because the padding is right there in the code.

The fix is to put padding on a <td>, not a <div>. The Word engine respects cell padding. It does not respect div padding. So any time you need space inside a column, wrap the content in a nested table and pad the cell:

<td width="300" valign="top">
  <table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">
    <tr>
      <td style="padding: 20px;">
        <!-- now your padding actually works in Outlook -->
      </td>
    </tr>
  </table>
</td>

Yes, it’s another layer of table. Yes, it’s annoying. No, you cannot skip it if you want consistent spacing in Outlook. This is exactly the kind of bug that doesn’t show up in local preview, because your local preview is Chrome and Chrome respects div padding just fine, which is what makes it so maddening – everything looks correct right up until it’s in front of a subscriber.

Zeroing out cellpadding, cellspacing, and border

Quick hits on the old HTML attributes you’ll see everywhere:

• cellpadding="0" and cellspacing="0" – zero these out on every layout table. They add default spacing that fights with your actual design. Control spacing yourself with <td> padding so you know exactly what’s happening.
• border="0" – kills the default table border. Forget this and you get faint lines around your cells in some clients. During development I sometimes set border="1" temporarily so I can see the table structure, then zero it out before shipping. Useful trick for debugging a layout that’s behaving strangely.
• For the Outlook gap issue where tables get mysterious spacing on the sides, mso-table-lspace: 0pt; mso-table-rspace: 0pt; in your inline styles cleans it up. One of those incantations you memorize and stop questioning.

Get those four things right – the 600px container, clean nesting, padding on cells not divs, and zeroed-out attributes – and you’ve got a foundation that holds in every client. The rest is decoration.

Ghost tables – the part that’s actually a skill

Here’s where we separate the people who know email from the people who read one tutorial. Anybody can write a <table>. The actual craft is the ghost table.

What a ghost table even is

A ghost table is a fixed-width table that exists only for Outlook, hidden from every other client inside a Microsoft conditional comment. The syntax looks like this:

<!--[if mso]>
<table role="presentation" width="600" align="center" cellpadding="0" cellspacing="0" border="0">
  <tr>
    <td>
<![endif]-->

<table role="presentation" width="100%" style="max-width: 600px;" cellpadding="0" cellspacing="0" border="0">
  <!-- your real content -->
</table>

<!--[if mso]>
    </td>
  </tr>
</table>
<![endif]-->

The <!--[if mso]> part is read by every Word-based Outlook build – 2007 all the way through 2024, plus the Microsoft 365 desktop versions still on the Word engine. Every other client on earth sees a regular HTML comment and ignores everything inside it. So Outlook gets a clean, fixed-width table to render into (which it understands), and everyone else gets your modern, flexible layout (which they understand). Best of both, with one ugly comment doing the negotiating.

This is the trick that powers the whole hybrid approach. You let modern clients use modern code, and you hand Outlook a rigid table it can’t screw up. Ghost tables are why your two-column block can stack beautifully on mobile in Apple Mail while still rendering as solid columns in a 2019 Outlook install.

Targeting specific Outlook versions

You can narrow the targeting if you need to. <!--[if mso 16]> hits the 2016/2019/2021 generation specifically. There are conditional flavors for different builds, and occasionally you’ll need them to fix a quirk in one version without affecting others. But for the vast majority of HTML email tables work, plain [if mso] is what you want. Don’t over-engineer the targeting until you have an actual reason to.

The mistake I made at 11pm before a launch

Here’s the ghost table failure mode, and yes I’m telling on myself. If you put the ghost table outside the conditional comment – if your <table> tags aren’t wrapped in [if mso] / [endif] properly – then the fixed-width ghost table renders in every client. Which means every client gets the rigid Outlook version instead of your nice fluid layout, and your email stops being responsive everywhere at once. On mobile it’ll blow out past the screen edge.

I did this once. Night before a product launch, tired, moved a block of code, fumbled the comment boundaries, didn’t re-test because “it was just a small move.” Sent. Got the screenshots the next morning. Learned my lesson permanently. Double-check your comment boundaries every single time you touch ghost table code. Count your opening and closing [if mso] blocks like you’re counting parentheses in a function.

When do you stop using ghost tables?

Eventually you’ll be able to drop them. Not yet. The honest guidance: keep ghost tables in your templates as long as classic Outlook is a meaningful chunk of your opens, and start removing them from new templates once your analytics show classic Outlook below roughly 5% of your audience. Audit that number quarterly. For a heavily mobile, B2C, course-creator audience you might hit that threshold in the next couple of years. For B2B and enterprise senders, you’re looking at 2028, 2029, possibly later. Don’t rip working ghost tables out of templates that already work just because the code feels dated. If it renders, leave it alone.

Accessibility – the HTML email tables mistake that makes you look amateur

This is the section most table tutorials either botch or skip entirely, which is wild, because getting it right takes about four seconds per table and getting it wrong actively harms people.

The problem

When a screen reader hits a <table>, its default assumption is that the table contains data. So it announces it. “Table. Two columns, three rows.” Then it reads the contents cell by cell, position by position, trying to give the listener a sense of the grid. For an actual data table, that’s helpful. For a layout table – which has no meaningful grid, it’s just scaffolding holding your hero image in place – it’s a disaster. The listener gets a stream of “row one, column one, row one, column two” nonsense wrapped around your content, and your email becomes genuinely unusable for anyone relying on a screen reader.

Now think about how many nested tables a typical email contains. The container, the sections, the columns, the padding wrappers. Each one gets announced. It’s an avalanche of structural noise burying your message.

The fix

Add role="presentation" to every single layout table.

<table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">

That attribute tells assistive technology to ignore the table’s structure entirely and just read the content inside it, in order, like it would read normal text. The “row one column one” avalanche disappears. The listener gets your actual message.

Every. Layout. Table. Not just the outer one. All of them. This is the one accessibility fix that delivers the most impact for the least effort in all of email, and it’s a single attribute. There’s genuinely no excuse to skip it.

The nuance nobody mentions

You might also have seen role="none" suggested for the same purpose. It does roughly the same job, but role="presentation" has wider and more reliable support across assistive technology, so use presentation. That’s the call.

And here’s the part the four-second tutorials never get to: if you have a real data table – an actual pricing grid, an order summary with line items and totals – do NOT add role="presentation" to it. That table is genuinely tabular data, and a screen reader user wants it announced as a table so they can navigate it properly and understand the relationship between rows and columns. Stripping the semantics from a real data table is just as bad as leaving them on a layout table. Knowing which is which is the difference between someone who copied a snippet and someone who understands what they’re building.

While we’re here

A few other accessibility basics that pair with proper table markup, because if a client’s asking about screen readers they’ll want the rest:

• Use real heading tags. <h1>, <h2>, and so on. Screen reader users navigate by jumping between headings, and most readers won’t treat bold-and-big text as a heading – it has to be an actual heading tag.
• Set lang and dir attributes on your content, especially if you’re sending in multiple languages. (This one’s relevant for anyone running launches for international or multilingual audiences – the screen reader needs to know what language to pronounce, and right-to-left languages need the direction flag.)
• Write meaningful link text. “Register for the workshop,” not “click here.” Screen reader users often pull up a list of just the links, and a screen full of “click here” tells them nothing.
• Mind your color contrast. The standard is 4.5:1 for normal text.

The accessibility pressure is increasing, not decreasing – WCAG 2.2 and the European Accessibility Act have made this a compliance question for a lot of senders, not just a nice-to-have. Build the habits now.

Where HTML email tables get ugly – an honest limits section

I’m not going to pretend this technique is a miracle that solves everything, because that’s the kind of marketing fluff that makes our whole industry exhausting. Tables have hard limits. Here’s where they fight back.

Three or more columns. Two columns are clean. Three columns are doable but fragile – the ghost tables nest deeper, the math on widths and gutters gets fiddly, and that “one missing tag eats the campaign” risk multiplies with every layer of nesting. I ship three-column layouts regularly, but I triple-check them and I budget more testing time. Four or more columns, I’d genuinely reconsider the design or stack smaller column groups inside a larger container.

Magazine-style asymmetric grids. If a designer hands you a layout with a big feature block and smaller items artfully wrapping around it, different content blocks at different widths, that pinterest-y staggered look – tables will not do that elegantly. You’ll fight it for hours and it’ll still look slightly off in Outlook. This is one of those moments where the right move is to push back on the designer and say, kindly, “this is gorgeous for the website and it’s going to look like a dropped deck of cards in 30% of email clients no matter what I do.” Have that conversation early.

Variable-height columns that need to align. A tall main column next to a short sidebar where something in the sidebar is supposed to line up with something specific in the main column – the valign="top" trick that handles vertical alignment in table cells has real limits, and sometimes you just have to accept the imperfection and move on.

Background images in cells. Classic Outlook won’t render a CSS background image. It’ll show your fallback background color instead. If you genuinely need that image to appear in Outlook – say it’s load-bearing for the design, not just decoration – you need a VML fallback inside an MSO conditional comment. It’s extra work and it’s not optional when the image matters.

And then there’s the white whale. The Outlook hairline. Outlook 2019 in particular has a habit of adding a 1px gap or a faint line on certain nested ghost tables, and it seems to depend on the user’s Windows DPI scaling settings, which means it shows up for some recipients and not others and you can’t reliably reproduce it on your own machine. I have lost actual hours to this. Whole afternoons. If you’ve cracked it – if you have a reliable fix – please write me a long, insufferably smug email about it, because I would genuinely love to know.

HTML email tables in real ESPs – what breaks where

The technique surviving in theory is one thing. The technique surviving whatever email service provider your client insists on using is a different and more painful thing. Quick field notes on the platforms I deal with most.

GetCourse

Relevant for a lot of my course-creator clients, especially in Russian-speaking markets where it’s huge. GetCourse handles layout, let’s say, creatively. It’ll sometimes truncate emails over a certain length, rewrite chunks of your HTML during template processing, and inject extra whitespace into your tables. The good news is that HTML email tables with percentage-based widths re-stabilize after the platform’s meddling better than a fully responsive media-query layout does. Pro tip that’s saved me more than once: don’t load web fonts via <link> tags in GetCourse – it strips them inconsistently. Inline your fallback font stack and move on.

Mailchimp

The classic template editor preserves table-based layouts reasonably well. The newer drag-and-drop builder re-inlines CSS aggressively, which can quietly break things that depend on multiple declarations on one element. If you’re hand-coding for Mailchimp, paste into the “code your own” template type, not the visual editor. The visual editor is where good code goes to get mangled.

Klaviyo, Braze, and the rest

• Klaviyo is generally cooperative, but its drag-and-drop blocks insert their own wrapping tables, which collide with custom ghost tables if you try to mix custom HTML blocks with native ones. Go fully custom or fully native; the bugs live in the mixing.
• Braze mostly leaves your HTML alone, which is lovely. The Liquid templating can produce weird indentation that makes debugging harder but doesn’t affect rendering. Test with realistic personalization tokens, not placeholder text.
• Salesforce Marketing Cloud respects table layouts well, but Content Builder can wrap your code in extra tables depending on how you structure content blocks. Use the HTML-paste block type rather than letting it compose around your markup.
• HubSpot strips MSO conditional comments under certain template configurations, particularly older drag-and-drop template types – which means your ghost tables vanish and Outlook gets the broken version. Use the coded email tool. If your team’s locked into the visual editor, you may have to compromise on ghost tables for those templates, and that’s a real cost worth flagging to whoever made the platform decision.

If your email looks fine in your code editor but breaks once it’s in the ESP, the platform is almost certainly rewriting something. The symptom “email table not rendering in Outlook after I uploaded it to the ESP” is usually the ESP eating your conditional comments or re-inlining your CSS. Check what the platform did to your code before you blame your code.

Testing your table layouts (and why your browser is lying to you)

Testing is the boring half of this job that everyone underestimates and everyone regrets underestimating. You cannot tell whether your HTML email tables work by looking at them in your browser. Your browser is Chrome (or Firefox, or Safari), and not one of your subscribers is reading email in a desktop browser with your dev tools open. You have to test where it’ll actually land.

Litmus

Still the industry default for serious QA, and I’ll recommend it with a giant asterisk. Litmus gives you screenshot previews across roughly 100 client and device combinations, including every Outlook version that matters – classic 2016, 2019, 2021, 2024, the new Outlook for Windows, Outlook for Mac, Outlook on the web, plus the iOS and Android apps. The dark mode previews alone are worth a lot, because Apple Mail’s dark mode inversion is aggressive enough to wreck a perfectly good design without warning. Litmus is genuinely excellent at catching version-specific quirks – the DPI hairlines, the subtle line-height differences between Outlook 2019 and 2021, the moment Gmail iOS started clipping emails over a size threshold. You will not find that stuff in a browser.

Now the asterisk, because somebody needs to say this plainly. Litmus was acquired by Validity, and on August 1, 2025 they quietly revised their pricing. The plan that used to be “Plus” at around $199/month became the new Core plan at $500 per month – that gets you 2,000 email previews, 5 user seats, plus a pile of Personalize impressions and analytics most small teams never asked for. There’s no cheap solo tier anymore. For an in-house enterprise team running dozens of campaigns a month, fine, the value holds. For a course creator doing one launch a quarter, or a freelancer testing a couple of emails a week, $500 a month to look at screenshots is genuinely hard to justify. I’m still subscribed because my client mix pays for it, but I’ve stopped recommending it as the automatic default.

Mailgun Inspect (formerly Email on Acid)

Email on Acid has been migrating into Mailgun Inspect, with the cutover for paying customers rolling through 2026. Core testing functionality is largely the same, plus newer accessibility checks aligned with WCAG 2.2. Historically Email on Acid sat around half the price of Litmus for comparable rendering coverage, and Mailgun Inspect has kept that positioning. Since the Litmus price hike, this is where I’d point most small-to-mid teams. If you’re shopping fresh and you don’t need Litmus’s analytics suite, start here.

The cheaper end and the real-hardware test

• Mailtrap – sandboxed inbox testing, good for development workflows, cheaper, less comprehensive on the full client-preview matrix.
• HTMLemail.io – simple, free, fine for quick sanity checks.
• Putsmail (by Litmus) – free way to fire test emails into your own inboxes.

And the thing the paid tools can’t replace: a real device. Litmus and Mailgun Inspect run virtual machines, and VMs are close to real but they’re not real. I keep a 2019 ThinkPad running an actual Outlook 2019 install on Windows 10 specifically as a reality check, and it catches things the virtual previews miss. Same for a physical iPhone with the Gmail app – iOS Gmail occasionally disagrees with the simulator in ways nobody’s documented. If you do nothing else: send the email to your own Gmail, Outlook, Apple Mail, and Yahoo accounts before every send. Yes, even small sends. Especially small sends, because that’s when people get lazy and that’s when it bites.

My actual workflow, for the record: build, run it through Litmus, fix what Litmus flags, send-to-self across all four major inbox types, fix whatever looks wrong on real devices, then send. It adds maybe 30 minutes. It has saved me from at least three “we accidentally broke the launch email” client calls that I can specifically remember, and those calls cost a lot more than 30 minutes.

What happens to HTML email tables after the Outlook transition

Let’s look forward, because you’re presumably building things meant to last and you want to know if you’re learning a dead skill. (You’re not, but let me show my work.)

The realistic five-year arc

• 2026 – 2027. HTML email tables and ghost tables are strictly necessary for any B2B sender or any list with meaningful corporate Outlook representation. The opt-out phase doesn’t even start until March 2027, so nobody’s being forced off classic yet. Build defensively.
• 2027 – 2028. Audience analysis starts mattering more than Microsoft’s defaults. If you’re sending to a 90%-mobile course-creator audience, you can start being more aggressive about dropping legacy code from new templates. If you’re sending to enterprise B2B, you absolutely cannot.
• 2028 – 2030. Ghost tables shift from “must have” to “maintained legacy fallback for the long tail.” The table backbone for structure outlives ghost tables specifically, because tables are still the most reliable cross-client layout method even after the worst client improves.
• Beyond 2030. Assuming Microsoft doesn’t pivot yet again (a real assumption to question, given how many times they’ve moved this timeline already), the technique fades into the background. Still works, just not something you teach in a workshop.

The reason tables outlive Outlook

Here’s what the “are tables dying” hot takes consistently miss: tables were never only about Outlook. The table-based, media-query-independent approach also survives a bunch of other hostile environments that have nothing to do with Microsoft:

• ESPs that strip or rewrite the <head> element (looking at you, GetCourse, and certain locked-down corporate Mailchimp and Salesforce setups).
• Email previews in messaging apps that don’t render external stylesheets.
• HTML email embedded into Slack, Teams, and other collaboration tools.
• Email forwarded into clients you genuinely cannot predict.
• Webmail apps that haven’t been updated since 2018 and never will be.

So even after classic Outlook is finally in the ground, there’s a solid argument for building emails whose structure doesn’t depend on modern CSS being respected. The whole approach is defensive engineering – it produces emails that work in environments you didn’t anticipate. That value doesn’t evaporate because Microsoft fixed one product.

What about Grid and container queries?

People ask. CSS Grid works in Apple Mail, doesn’t work in Outlook desktop, and Gmail’s support is partial – so we’re a couple of years out, minimum, from treating it as a primary layout method, and even then you’ll want a table fallback for the long tail. Container queries are the genuinely exciting one on the horizon, since they’d let email components respond to their container rather than the viewport, which would be huge for reusable blocks across different template widths. Browser support is arriving; email client support is lagging behind as usual. I’d guess 18 to 24 months before it’s safely usable as a progressive enhancement in email, longer before it’s a foundation. Watch it. Don’t bet a campaign on it yet.

My honest recommendation for the next few years

• Keep HTML email tables as your structural base layer for any client with a mixed or unknown audience.
• Treat ghost tables as a fallback you’ll gradually phase out over the next three to four years, not something to rush.
• Layer modern CSS on top – media queries, dark mode targeting, selective div-based components where support is proven.
• Audit your audience analytics quarterly. Classic Outlook under 5% of opens? Start dropping legacy code from new templates.
• Don’t tear working tables out of working templates because the code feels old. Old and working beats new and broken every time.

FAQ – HTML email tables

Do HTML emails still need tables in 2026?

Yes. Classic Outlook on Windows still renders email with Microsoft Word’s engine, which doesn’t support Flexbox, CSS Grid, or reliable div-based layout, and Microsoft will support classic Outlook through at least 2029. Until that audience disappears from your list, tables remain the only layout method that holds up across every major email client.

Why do emails use tables instead of divs?

Because divs render inconsistently in classic Outlook, which is exactly the client you can’t ignore for B2B and corporate audiences. Divs work everywhere modern – Apple Mail, Gmail, the new Outlook – but they fall apart in the Word-based engine. Tables render predictably everywhere, so they stay the structural backbone.

What is a ghost table in email?

A ghost table is a fixed-width table wrapped in a Microsoft conditional comment (<!--[if mso]>) so it’s visible only to Word-based Outlook. Every other client treats it as a regular comment and ignores it. This lets you give Outlook a rigid layout it can render correctly while everyone else gets your modern, flexible code.

What does role=”presentation” do on an email table?

It tells screen readers to ignore the table’s structure and read the content inside it as normal text, in order. Without it, assistive technology announces every layout table as a data table – “table, two columns, three rows” – and reads it cell by cell, which makes the email unusable for screen reader users. Add it to every layout table.

What width should an HTML email table be?

The standard content width is 600px. It’s convention rather than a rule – wide enough to be useful, narrow enough to fit comfortably on most screens, and it gives mobile a sensible layout to work with. You’ll see 640px occasionally. Six hundred is the safe default for the inner content table, with the outer table set to 100% width.

Can tables make a responsive email?

Yes. You combine percentage-based widths, a max-width cap, and either media queries or the hybrid div-inside-ghost-table technique to get layouts that adapt to screen size and stack on mobile. The table provides the structure; the responsiveness layers on top. The fluid hybrid approach builds directly on the table foundation covered here.

Why does my table look broken in Outlook but fine in Gmail?

Almost always one of these: padding declared on a <div> instead of a <td> (Outlook ignores div padding), a missing closing tag (Outlook doesn’t auto-correct sloppy markup the way browsers do), a missing or misplaced ghost table, or border="0" left off your tables. Your browser preview is forgiving; the Word engine is not. Test in real Outlook before you ship.

Is it better to use tables or a framework like MJML?

It depends on your needs, but understand that frameworks like MJML compile to table-based, inline-styled HTML – so you’re using HTML email tables either way, you’re just not hand-writing them. Hand-coding gives you total control and smaller output; a framework gives you speed and saves you from typing nested tables by hand. Many teams use a framework and hand-tune the output.

Will tables stop working when the new Outlook takes over?

No. Tables will keep rendering fine in the new Outlook and every other client – they’re valid HTML everywhere. What changes is that they’ll stop being mandatory once classic Outlook’s share of your audience collapses, which on the current timeline means 2028, 2029, or later depending on how corporate your list is. Working table-based emails will keep working indefinitely.

Can a non-developer build HTML email tables from scratch?

Realistically, no. Editing an existing table-based template – swapping copy, images, links, colors – is doable for a careful marketer. Building one from a blank file, or restructuring columns and layouts, needs someone who can read and write HTML and CSS confidently. If your team doesn’t have that in-house, this is exactly the kind of work to hand to a specialist rather than fight through yourself.

Closing thoughts

HTML email tables are not glamorous. Nobody’s giving a conference keynote about nested <td> elements. There are no breathless threads celebrating the elegance of a ghost table. It’s workmanlike, defensive, slightly miserable engineering that exists because email clients are inconsistent and the industry has never managed to standardize, and because Microsoft decided in 2007 to render your emails with a word processor and then took the better part of twenty years to reconsider.

But the emails I build with proper table structure work. They work when the ESP rewrites the <head>. And when a client forwards the campaign into a 2019 Outlook install in a basement office. They work in webmail apps I’ve never heard of and dark mode I’ve actually accounted for. They’ll keep working straight through the Outlook transition, and they’ll still be working in 2029 when half my predictions in this article turn out to be wrong about which specific client did what when.

If you’re a producer or a course creator wondering whether your developer actually knows email – ask them about ghost tables. Ask them what role="presentation" does and why a data table is different. Ask whether they test in real Outlook or just trust the Litmus screenshots. The answers will tell you everything.

And if you need emails that survive Outlook for as long as Outlook is a thing people open – that’s the work I do. Send me a brief. I respond within the day, I don’t vanish mid-project, and I’ll show you the test results before you hit send.

I’ve got a couple of follow-ups in progress – one going deeper on the fluid hybrid responsive technique that builds on everything here, one on dark mode patterns, and one on container queries and how they might reshape email layout over the next two years. They’ll be on the blog when they’re ready. Subscribe if you want them in your inbox – ideally an inbox that renders this email correctly, which, if I’ve done my job, is all of them.