Quick answer: Nested tables are HTML tables placed inside the cells of other tables. Email developers use them to build reliable, multi-column layouts that hold their shape across email clients – especially classic Outlook, which renders email with Microsoft Word and ignores most modern CSS.
Nested tables are the thing every email developer learns early and then quietly relies on forever. The idea is plain. You put a <table> inside the <td> of another <table>, and you keep going until your layout holds. That is it. No magic. The reason we still do this in 2026, when the rest of the web moved on around 2012, comes down to one stubborn piece of software. We will get to that. For now, just know that nested tables are less a clever trick and more a survival tool.
This entry walks through what they are, why they exist, how deep is too deep, where they hurt accessibility, and whether you even still need them. Spoiler on that last one: yes, for a while yet. But the ground is moving.
- What are nested tables in email
- The Russian doll structure
- Why not just use divs
- Why nested tables exist (the Outlook problem)
- A short history of how we got stuck
- The double-width trick
- When to nest a table (and when not to)
- Nest a new table when
- Do not nest when
- The three-deep rule
- Nested tables and accessibility (the part everyone gets wrong)
- The role that does not cascade
- Are nested tables still necessary in 2026
- The real Outlook timeline
- What the next five years look like
- Nested tables vs divs and modern CSS
- Common nested table mistakes (and how testing catches them)
- A note on testing tools
- Frequently asked questions
- What is a nested table in HTML email?
- Why do emails use nested tables instead of divs?
- How many levels deep can you nest tables in email?
- Do nested tables hurt email accessibility?
- Are nested tables still needed with the new Outlook?
- How do I test nested tables across email clients?
- Key takeaways
What are nested tables in email
A table in HTML has three core parts. You have the table itself (<table>), a row (<tr>), and a cell (<td>). Content goes in the cell. Nesting just means one of those cells holds another whole table.
Here is the smallest possible version:
<table role="presentation" width="600" cellpadding="0" border="0">
<tr>
<td>
<!-- a nested table lives here -->
<table role="presentation" width="100%" cellpadding="0" border="0">
<tr>
<td>Your actual content</td>
</tr>
</table>
</td>
</tr>
</table>
That is the whole concept. Tables inside tables. The trouble starts when “tables inside tables” turns into “tables inside tables inside tables inside tables,” which it does, fast.
The Russian doll structure
Most production emails use a layered version of nested tables that people call the Russian doll. It has three rings.
- A wrapper table that fakes the
<body>, because some clients strip body styling. - A full-width background table set to 100%, which paints the colour to the screen edges.
- A fixed-width content table, usually 600 to 640 pixels, that holds the actual email.
So the flow reads like this: body, then a 100% canvas table, then a centred 640px card, then your content. Each ring exists for a reason. The canvas gives you a background colour that fills the window. The card keeps your line length sane. Strip any ring out and something breaks in some client. I have tried, and it breaks.
Why not just use divs
Fair question. On the web you would reach for a <div> and margin: 0 auto, and you would be done in thirty seconds. In email that centring fails in places you need it most. Classic Outlook ignores most styling on divs and will not size or position them the way you wrote. Tables, for all their ugliness, give you cell-by-cell control that holds up. That is the trade. Cleaner code versus code that actually renders.
Why nested tables exist (the Outlook problem)
Here is the thing nobody outside email quite believes. Classic Outlook for Windows renders email using the Microsoft Word engine. Yes, Word. The document program. Specifically the 2007-era rendering core. So in 2026 you are coding for a layout engine that predates the iPhone.
Word was never built to render web pages. It does not care about your margin or padding in places. It throws random white lines between cells and misaligns things for no reason you can name. Float and position are out. Flexbox and grid may as well be science fiction. So you fall back on the one structural tool Word handles predictably: the table.
Given how widely Outlook for Windows is used, developers adopted patterns needed only to keep emails rendering there. It was an Outlook-first habit, not a user-first one.
That quote, paraphrased from the Email Markup Consortium, sums up the whole mess. Nested tables are not best practice in any modern sense. They are a workaround that became a habit because one client refused to grow up.
A short history of how we got stuck
It helps to know why this is even a thing. Back in the late 1990s, the whole web was built with tables. Designers used <table> tags to lay out pages, because CSS was young and barely supported. Then the web grew up. Standards improved. Layout moved to CSS, and tables went back to their real job: holding data.
Email never got that memo. Email clients froze in time. Many of them, Outlook worst of all, kept rendering like it was 2003. So while the web moved on, email stayed behind, and nested tables stayed mandatory. We are basically maintaining a layout technique the rest of the industry abandoned twenty years ago. It is strange when you say it out loud.
The double-width trick
Here is a specific quirk worth burning into memory. When you set a width on a nested table cell, set it twice.
<td width="640" style="width:640px;">
Why both? Because the engines disagree. Outlook for Windows reads the HTML attribute, width="640". WebKit clients like Apple Mail and the iPhone read the CSS, width:640px. Give one and skip the other, and you will get a perfect render in one place and a squashed mess in another. State the width in both languages and everybody listens. This is the kind of thing that drives people out of email development, honestly. It is also the kind of thing that keeps the rest of us employed.
When to nest a table (and when not to)
Most tutorials hand you nested tables and never tell you when to stop. That is the actual skill. Anyone can nest. Knowing when not to is what separates a clean build from a tangled one.
Nest a new table when
- You change the number of columns in a row. New column count, new table. Always.
- You need a coloured border around a block. Wrap the inner table in an outer one with a background colour and a little extra width.
- You need padding that classic Outlook would otherwise eat. A nested cell with its own padding survives where shorthand does not.
- You are building a modular block you plan to reuse. A self-contained table copies and pastes without wrecking the rest.
On that first point, there is a concrete reason. colspan does not behave reliably in older Outlook versions. So instead of merging cells across a row, you start a fresh table whenever the column count shifts. It feels redundant. It is also the safe move.
Do not nest when
- A single cell with padding would do the job. Do not add a table to add a gap.
- You are already three levels deep. That is the ceiling for most layouts.
- You are nesting out of habit rather than need. Stop and ask what the extra table buys you.
The three-deep rule
The old hands have a guideline: if you must nest, try not to go deeper than three tables. There are real costs to going deeper.
| Cost of over-nesting | What actually happens |
|---|---|
| Maintainability | You lose track of which </table> closes which <table> |
| File size | Markup bloats, and Gmail clips messages over roughly 102KB |
| Accessibility | Screen readers struggle to navigate deeply nested layouts |
| Debugging | One missing tag cascades into a fully broken render |
My personal smell test is irrational but it works. If I cannot tell which closing tag matches which opening tag without scrolling and counting, the layout is over-nested. Time to flatten it. Usually two of those tables were doing nothing a single cell could not handle.
Nested tables and accessibility (the part everyone gets wrong)
This is where a lot of otherwise solid emails fall apart, and where most generic guides go quiet.
A screen reader does not know your table is just for layout. It hits the table and starts announcing structure – “Table, row one, column one,” then the next cell, then the next. A blind subscriber hears all that scaffolding before they ever reach your headline. With nested tables, multiply that noise by every layer you added. It is a genuinely bad experience.
The fix is one attribute:
<table role="presentation" ...>
role="presentation" tells assistive tech to treat the table as decoration, not data. Skip the structure, read the content. Simple.
The role that does not cascade
Now the gotcha that makes this whole section worth bookmarking. role="presentation" does not inherit. Setting it on your outer table does nothing for the tables nested inside it. Each table needs its own role="presentation". Every single one. Miss an inner table and the screen reader starts announcing rows and columns again, right in the middle of your email.
So the rule is blunt. Every layout table in your build gets the attribute. No exceptions, no shortcuts. Bake it into your boilerplate snippet so you never have to remember. That is the only way I have found to stay consistent across a long file full of nested tables.
One caution. If a table holds genuine tabular data – a pricing grid, a schedule – leave the role off. You want that one read as a real table.
role="presentation"is for layout, not for everything.
There is also a deeper-than-cosmetic problem here. Heavily nested layouts make it more likely a screen reader gets stuck inside a cell or loses its place. So accessibility is one more reason to keep your nesting shallow. Fewer tables, fewer places to trip.
And this stopped being optional. The European Accessibility Act came into force in mid-2025. If you email people in the EU, accessible markup is now a compliance question, not a nice-to-have. Skipping role="presentation" on your nested tables is no longer just rude. It can be a problem.
Are nested tables still necessary in 2026
Here is the part everyone gets wrong in both directions. Some people say tables are dead. Some people code like it is still 2009. Both are off.
The big shift is real. The new Outlook for Windows ditched the Word engine. It now runs a proper web-based, Chromium-style rendering core, much like Outlook on the web. That means real HTML and CSS support. Ghost tables and VML, the old Outlook hacks, are no longer needed there. In the new Outlook, nested tables become optional, not mandatory.
So why am I telling you to keep using them? Because of timing.
The real Outlook timeline
The “tables are dying” crowd loves to point at an end date for Word-rendered Outlook. The date keeps moving. Here is where things actually stand, pulled from current Microsoft and industry sources.
| Milestone | Status as of mid-2026 |
|---|---|
| Outlook 2016 and 2019 | Out of support since October 2025 |
| New Outlook opt-out (enterprise) | Delayed to March 2027 |
| Cutover (no switching back) | No earlier than March 2028 |
| Classic Outlook support | Continues until at least 2029 |
Read that bottom row again. Classic Outlook, the one running Word, sticks around until at least 2029. Microsoft already pushed the enterprise opt-out from April 2026 to March 2027. Going by their track record, do not be shocked if it slips again.
So nested tables are not going anywhere for years. Anyone telling you to drop tables in 2026 is coding for their own inbox, not their audience’s. The honest move is the hybrid approach. Build a solid table base that works at any width. Then layer modern CSS on top for the clients that support it. Tables for the floor, CSS for the polish.
What the next five years look like
I do not own a crystal ball, but the direction is fairly clear.
- 2026 to 2027. Classic Outlook share bleeds slowly. Nested tables stay mandatory for most senders. You keep your conditional comments and your ghost tables for that audience.
- 2027 to 2028. New Outlook becomes the default for more people. You start trusting CSS more in your base layout, while still shipping a table fallback.
- 2028 to 2029. If cutover actually lands, the table requirement softens for real. Leaner markup becomes safe for a wider slice of your list.
- Across all of it. Accessibility moves from optional to audited.
role="presentation"on nested tables goes from good habit to expected baseline.
The technique that replaces blind nesting will not be “no tables.” It will be “fewer tables, used on purpose.” Frameworks already point this way. Tools like MJML and Foundation for Emails let you write cleaner syntax that compiles down to nested tables under the hood. So even when you stop hand-writing them, understanding nested tables still matters. The machine is just doing the nesting for you.
Nested tables vs divs and modern CSS
A quick, honest comparison. No tribalism here. Each approach has a job.
| Approach | Strengths | Weaknesses |
|---|---|---|
| Nested tables | Render reliably in classic Outlook; precise control | Verbose; accessibility overhead; harder to maintain |
| Divs and CSS | Clean code; better accessibility; modern | Break in classic Outlook; need fallbacks |
| Hybrid (tables + CSS) | Best coverage today; works everywhere | More work upfront; two systems to manage |
For most senders in 2026, the hybrid row is the answer. You are not picking a side. You are picking coverage. Nested tables carry the load where they must, and CSS handles the clients that can take it.
One practical tip on the hybrid approach. Keep your base layout fluid with percentage widths and a max-width. That way it survives in any client, even ones with no media query support. Then add media queries on top for the clients that read them. Apple Mail fully supports them. Gmail and the new Outlook support them partially, which is usually enough for basic mobile stacking. Classic Outlook for Windows ignores media queries entirely – but since it is not responsive anyway, it just renders your fixed desktop width. The nested tables hold it together underneath.
Common nested table mistakes (and how testing catches them)
I have shipped enough of these to know the patterns. Here are the ones that bite.
- A missing closing tag. One stray
<td>with no</td>and the whole layout collapses. Deeply nested tables make this easy to miss. - Over-nesting past three levels. Covered above. It bloats the file and tangles the structure.
- Width declared once. Forgetting the HTML attribute or the CSS, so one engine guesses and gets it wrong.
- No
role="presentation"on inner tables. The accessibility leak that hides until someone actually uses a screen reader. - Trusting your own preview. Your inbox is not 40 inboxes. The one client you skipped is the one that breaks.
That last point is the real one. You cannot eyeball nested tables across every client by hand. You need to see the actual renders.
A note on testing tools
This is where testing platforms earn their keep. They preview your email across dozens of real clients and flag the accessibility gaps before you hit send.
Two things worth knowing, because the landscape shifted recently.
Litmus changed its pricing hard. After Validity acquired it, the cheap entry tiers vanished. As of 2026 the Core plan starts at $500 per month for 5 users and 2,000 previews. The old $99 Basic plan is gone. For a solo freelancer that stings. For a team shipping weekly, the time saved can still pencil out.
Email on Acid (now under Sinch) is the more budget-friendly competitor, and a lot of small shops moved to it after the Litmus hike.
One more, since people still ask: Putsmail, the old free send-a-test tool, is no longer available. If a tutorial points you there, the tutorial is stale.
Whichever you pick, the point stands. Test your nested tables somewhere real before they reach subscribers. Outlook will find the one mistake you did not.
Frequently asked questions
What is a nested table in HTML email?
A nested table is an HTML table placed inside the cell of another table. Email developers use nested tables to build structured, multi-column layouts that render consistently across email clients. The technique exists mainly to control layout in classic Outlook, which uses the Word engine and ignores modern CSS positioning.
Why do emails use nested tables instead of divs?
Because classic Outlook for Windows renders email with Microsoft Word, not a browser. It ignores most styling on divs and cannot position them reliably. Nested tables give cell-by-cell control that holds up in that engine. Until Word-rendered Outlook fully retires, tables remain the safe choice for layout.
How many levels deep can you nest tables in email?
Three levels is the working ceiling for most layouts. You can go deeper, but every extra layer adds file size, hurts maintainability, and makes screen reader navigation worse. If you cannot trace which closing tag matches which opening table, you have over-nested. Flatten it back toward three.
Do nested tables hurt email accessibility?
They can, if you skip one attribute. Screen readers announce table structure aloud unless you add role="presentation". The catch is that this role does not cascade, so every nested table needs its own. Miss an inner table and the screen reader starts reading rows and columns mid-email.
Are nested tables still needed with the new Outlook?
In the new Outlook for Windows, no – it uses a web engine and supports modern CSS. But classic Outlook stays supported until at least 2029, and its enterprise rollout was delayed to 2027. So nested tables remain necessary for most senders today. Use a hybrid approach: table base, CSS on top.
How do I test nested tables across email clients?
Use a testing platform that previews real renders across many clients. Litmus now starts at $500 per month after its 2025 price change. Email on Acid is the cheaper alternative. The free Putsmail tool is no longer available. Whatever you choose, never trust a single inbox preview.
Key takeaways
- Nested tables are tables inside tables, the backbone of HTML email layout.
- They exist because classic Outlook renders with the Word engine and ignores modern CSS.
- Three levels deep is the practical limit. Deeper costs you file size, sanity, and accessibility.
- Add
role="presentation"to every layout table. The role does not inherit. - They are still required in 2026 and likely through 2029. The hybrid approach wins.
- Test on real clients. Outlook will find the mistake your inbox hid.
Nested tables are not elegant. They are not modern. But they work, and “works everywhere” still beats “clean but broken in Outlook.” Keep them shallow, keep them accessible, and keep testing. The day you finally retire them is coming. It is just not today.
« Back to Glossary Index
