If you come from modern frontend development, using tables for layout probably feels wrong. In web development, we moved on years ago. We use semantic HTML, flexbox, CSS grid, utility classes, components and clean layout systems.
HTML email development plays by a different set of rules.
For reliable HTML email layouts, tables are still the safest choice for the main structure of your email. Divs can be useful inside table cells for small styling tasks, but they should not be trusted as the foundation of a production email layout, especially if your campaign needs to work in Outlook, Gmail, Apple Mail and mobile clients.
The practical answer is simple:
| Layout technique | Safe for primary email layout? | Best use case |
|---|---|---|
| Tables | Yes | Main structure, columns, spacing, wrappers |
| Divs | Sometimes | Small content wrappers inside table cells |
| Flexbox | Risky | Progressive enhancement only |
| CSS Grid | Risky | Experimental or controlled environments |
| Hybrid table layout | Yes | Responsive layouts with better mobile behavior |
Desktop versions of Outlook remain one of the main reasons for this. Outlook 2007-2019 and the desktop version of Outlook Office 365 use Microsoft Word as their rendering engine, which creates many of the classic HTML email rendering problems developers still deal with today.
Why This Debate Still Exists
The “tables vs. divs” debate exists because HTML email looks like web development from the outside. You write HTML. You write CSS. You preview something in a browser. It seems familiar.
Then you send the same email to Outlook desktop and everything shifts.
The issue is not that divs are bad. Divs are perfectly normal in web development. The issue is that email clients do not behave like modern browsers. Some clients support modern CSS well. Others partially support it. Others strip, rewrite or ignore parts of your code.
That is why email developers still rely on table-based layouts. Tables are not used because they are elegant. They are used because they are predictable.
If you are new to this discipline, read this first: Why HTML Email Is So Different from Web Development.
The Real Problem with Div-Based Email Layouts
A div-based layout may look fine in a browser preview. It may even look fine in Apple Mail. But that does not mean it is production-ready.
Here is a common pattern a web developer might try:
<div style="max-width:600px; margin:0 auto; display:flex;">
<div style="width:50%; padding:20px;">
<h2>Product Feature</h2>
<p>This column contains text.</p>
</div>
<div style="width:50%; padding:20px;">
<img src="image.jpg" width="260" alt="Product image">
</div>
</div>This code is clean for the web. For email, it is fragile.
The main risks are:
- Outlook may ignore or mishandle widths and padding applied to divs.
- Flexbox behavior is not consistent across all relevant email clients.
- Some clients may stack content unexpectedly.
- Some clients may preserve the content but break the visual layout.
- Debugging the issue after the campaign is built can take longer than using tables from the beginning.
In HTML email, the cleanest-looking code is not always the safest code.
What Works, What Breaks, and What Needs a Fallback
| Technique | Works well in | Breaks or becomes risky in | Recommended fallback |
|---|---|---|---|
| Table-based layout | Most major email clients | Complex nested structures can become hard to maintain | Keep tables simple and modular |
| Div-based layout | Apple Mail and some modern webmail clients | Outlook desktop and clients with inconsistent CSS support | Use tables for structure |
| Flexbox | Some modern clients | Partial support, Gmail edge cases and Outlook inconsistency | Use table columns |
| CSS Grid | Some modern clients | Not safe enough for universal production emails | Use nested tables or hybrid layouts |
| Media queries | Many mobile clients | Some clients ignore them | Build a readable default layout |
| Inline CSS | Broadly reliable | Can become hard to maintain manually | Use an inliner in your workflow |
The Safer Table-Based Version
Here is a more email-safe version of the same two-column layout:
<table role="presentation" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr>
<td align="center" style="padding:0 16px;">
<table role="presentation" width="600" cellspacing="0" cellpadding="0" border="0" style="width:100%; max-width:600px;">
<tr>
<td class="stack-column" width="50%" valign="top" style="padding:20px; font-family:Arial, Helvetica, sans-serif;">
<h2 style="margin:0 0 12px; font-size:22px; line-height:28px; color:#111111;">
Product Feature
</h2>
<p style="margin:0; font-size:16px; line-height:24px; color:#333333;">
This column contains text and keeps its structure more reliably across email clients.
</p>
</td>
<td class="stack-column" width="50%" valign="top" style="padding:20px;">
<img src="image.jpg" width="260" alt="Product image" style="display:block; width:100%; max-width:260px; height:auto; border:0;">
</td>
</tr>
</table>
</td>
</tr>
</table>For mobile stacking, you can add this CSS in the email <style> block:
@media only screen and (max-width: 600px) {
.stack-column {
display: block !important;
width: 100% !important;
max-width: 100% !important;
}
}This does not mean every email client will behave identically. Nothing in HTML email is 100% guaranteed. But this pattern gives you a much safer default than a div-based flex layout.
Why Tables Are Still the Backbone of HTML Email
Tables give email developers control over the parts of layout that break most often:
- Container width
- Column width
- Alignment
- Vertical spacing
- Nested sections
- Background colors
- Image placement
- CTA positioning
A table-based layout also degrades more predictably. If a media query fails, the table structure usually remains readable. If a flex layout fails, the whole section can collapse, stretch, overlap or lose its intended column behavior.
That is the difference between a layout that is slightly imperfect and a layout that is broken.
For a broader list of common production mistakes, read: How to Avoid Common Pitfalls in HTML Email Development.
But Are Tables Bad for Accessibility?
Tables used for layout can create accessibility problems if they are not coded properly. Screen readers may interpret layout tables as data tables and announce rows, columns and structure that are irrelevant to the subscriber.
That is why layout tables should include:
role="presentation"Example:
<table role="presentation" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr>
<td>
Your email content goes here.
</td>
</tr>
</table>This tells assistive technologies that the table is being used for layout, not for tabular data.
Important distinction: if you are displaying real data in a table — for example, invoice rows, event schedules or pricing comparisons — do not use role="presentation" on that data table. Use proper table semantics instead.
When You Can Use Divs in HTML Email
This article is not saying “never use divs”. That would be too simplistic.
You can use divs in HTML emails when they are not responsible for the main layout.
Reasonable uses for divs include:
- Wrapping a small block of text inside a table cell.
- Applying a background color inside a controlled section.
- Creating a minor visual grouping.
- Supporting progressive enhancement in modern clients.
- Adding non-critical styling that can safely degrade.
Example:
<td style="padding:24px; font-family:Arial, Helvetica, sans-serif;">
<div style="font-size:14px; line-height:20px; color:#666666;">
This small wrapper is acceptable because the table cell controls the layout.
</div>
</td>This is different from using divs as the layout system itself.
A good rule:
Use tables for structure. Use divs only when the email still works without them.
When Flexbox or CSS Grid Might Be Acceptable
Flexbox and CSS Grid are not automatically forbidden. They can be useful in very specific cases.
You might consider them if:
- You are building an internal email for a controlled client environment.
- You know exactly which email clients your audience uses.
- You have analytics showing that Outlook desktop is irrelevant for your list.
- You have a fallback layout for clients that do not support the CSS.
- The layout enhancement is non-critical.
You should avoid them if:
- The email is going to a broad B2B audience.
- Outlook desktop matters.
- The layout must be pixel-consistent.
- You cannot test across multiple clients.
- The design depends entirely on flex or grid behavior.
In public marketing, newsletter and transactional emails, flexbox and grid are better treated as progressive enhancements — not as the foundation.
For more about client inconsistencies, read: Cross-Client Chaos: Navigating the Email Jungle.
A Practical Layout Decision Framework
Use this simple decision framework before choosing your email layout method.
| Question | If yes | If no |
|---|---|---|
| Does this email need to work in Outlook desktop? | Use tables | You may consider progressive CSS |
| Is this a marketing or transactional email? | Use tables | Controlled experiments are safer |
| Is the design multi-column? | Use table columns | A simple single-column div may be acceptable |
| Can the layout break without harming the message? | Progressive enhancement is possible | Use safer table structure |
| Will you test in Litmus, Email on Acid or real inboxes? | You can be more ambitious | Stay conservative |
| Is accessibility important? | Use role="presentation" on layout tables |
Still use readable structure |
The more uncertain your audience and testing coverage are, the more conservative your layout should be.
The Email-Safe Layout Pattern I’d Actually Ship
For most production emails, I would start with this pattern:
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Email</title>
<style>
@media only screen and (max-width: 600px) {
.container {
width: 100% !important;
}
.stack-column {
display: block !important;
width: 100% !important;
max-width: 100% !important;
}
.mobile-padding {
padding-left: 24px !important;
padding-right: 24px !important;
}
}
</style>
</head>
<body style="margin:0; padding:0; background-color:#f4f4f4;">
<table role="presentation" width="100%" cellspacing="0" cellpadding="0" border="0" style="background-color:#f4f4f4;">
<tr>
<td align="center" style="padding:24px 16px;">
<table role="presentation" class="container" width="600" cellspacing="0" cellpadding="0" border="0" style="width:600px; max-width:600px; background-color:#ffffff;">
<tr>
<td class="mobile-padding" style="padding:32px; font-family:Arial, Helvetica, sans-serif;">
<h1 style="margin:0 0 16px; font-size:28px; line-height:34px; color:#111111;">
Reliable HTML Email Layout
</h1>
<p style="margin:0 0 24px; font-size:16px; line-height:24px; color:#333333;">
This structure uses tables for layout, inline CSS for critical styles and media queries for mobile improvements.
</p>
<table role="presentation" cellspacing="0" cellpadding="0" border="0">
<tr>
<td align="center" bgcolor="#111111" style="border-radius:4px;">
<a href="https://example.com" style="display:inline-block; padding:14px 22px; font-family:Arial, Helvetica, sans-serif; font-size:16px; line-height:20px; color:#ffffff; text-decoration:none;">
Read more
</a>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
</table>
</body>
</html>Use this as a starting point, not as a universal template for every campaign. Every email still needs testing.
If you need to generate CTA code quickly, try the HTML Email Button Generator.
Common Mistakes When Using Tables in HTML Email
Tables are safer, but they can still be used badly.
1. Nesting too deeply
Nested tables are normal in email, but too many layers make your code harder to maintain and debug.
Use a new nested table only when it solves a real layout problem.
2. Forgetting role="presentation"
If the table is for layout, add role="presentation".
3. Depending only on CSS width
Use HTML attributes and inline styles together when width matters.
<table width="600" style="width:600px; max-width:600px;">4. Using empty table cells for large spacing
For small spacers, empty cells can work. But do not build an entire layout out of empty cells. Use padding where it is safe, and test Outlook carefully.
5. Forgetting mobile behavior
A desktop table layout can be technically correct and still be painful on mobile. Plan how columns will stack.
6. Treating browser preview as final testing
A browser preview is useful for basic development. It is not an email rendering test.
Send real tests. Use preview tools. Check Gmail, Outlook, Apple Mail and mobile clients.
Quick Testing Checklist
Before sending a table-based HTML email, check this:
- Main structure uses tables, not divs.
- Layout tables include
role="presentation". - Critical styles are inline.
- Images have width attributes and inline
height:auto. - Buttons are HTML-based, not image-only.
- Multi-column sections have a mobile stacking plan.
- Email still reads correctly if media queries fail.
- Outlook desktop has been tested.
- Gmail mobile has been tested.
- Dark mode has been reviewed.
- Links and CTAs have been checked.
- Alt text is present where needed.
If you are just starting with HTML email, this primer will help: Beginner’s Guide to HTML Email: From 0 to Hero.
FAQ: Tables vs. Divs in HTML Email
Can I use divs in HTML emails?
Yes, but avoid using divs as the main layout system. Divs are safer when used inside table cells for small, non-critical styling tasks. For wrappers, columns and structural layout, tables are still the safer choice.
Are tables still necessary for HTML email?
For broad production emails, yes. Tables remain the most reliable way to structure HTML emails across Outlook, Gmail, Apple Mail, Yahoo Mail and mobile clients.
Does flexbox work in HTML email?
Sometimes, but not reliably enough for universal email layout. Flexbox can work in some modern clients, but support is partial or inconsistent, so it should be treated as progressive enhancement.
Does CSS Grid work in HTML email?
CSS Grid has support in some clients, but it is not a safe default for production email campaigns. Use tables or hybrid table layouts when the layout must survive across major clients.
Are table-based emails bad for accessibility?
Not if they are coded correctly. Layout tables should use role="presentation" so screen readers do not interpret them as data tables. Real data tables should keep proper table semantics.
Should every HTML email be 600px wide?
Not always, but 600px remains a common and safe container width for many marketing emails. You can also use fluid or hybrid layouts with width:100% and max-width:600px.
Do tables guarantee perfect rendering everywhere?
No. Nothing guarantees perfect rendering in every email client. Tables simply reduce the risk and give you a more predictable foundation than div-based layouts.
Should I use MJML instead of hand-coded tables?
MJML can speed up production and generate table-based email code for you. It is useful, but you still need to understand the underlying table structure when debugging real client issues.
The Practical Answer
For modern websites, divs, flexbox and CSS grid are the right tools.
For HTML emails, tables still win because email clients are fragmented, inconsistent and often years behind modern browser behavior. The goal is not to write the prettiest code. The goal is to ship an email that renders clearly, reads well and survives real inbox conditions.
Use tables for the layout. Use inline CSS for critical styles. Use divs only when the email does not depend on them. Treat flexbox and grid as progressive enhancements. And always test before sending.
That is not old-fashioned. That is professional HTML email development.