A responsive HTML email uses a fluid outer layout, a constrained content container, flexible images, and small-screen enhancements that do not break the default message.
The safest approach is hybrid: make the base HTML usable everywhere, then add media queries for clients that support them. Responsive CSS should improve the message, not rescue it.
The responsive email formula
Use these five rules as a starting point:
- Set the outer table to
width="100%". - Constrain the inner content to roughly 600 pixels.
- Add side padding so content does not touch a phone's edges.
- Make large images fluid with
max-width:100%;height:auto. - Use media queries only for targeted enhancements such as stacked columns and adjusted spacing.
<table role="presentation" width="100%" border="0" cellpadding="0" cellspacing="0">
<tr>
<td align="center" style="padding:24px 16px">
<table role="presentation" width="600" border="0" cellpadding="0" cellspacing="0"
style="width:100%;max-width:600px">
<tr>
<td style="padding:40px 32px">
<h1 style="margin:0;font-size:32px;line-height:38px">Monthly report</h1>
</td>
</tr>
</table>
</td>
</tr>
</table>
This “fluid outside, fixed maximum inside” pattern works even when a media query is removed.
Start mobile first
Mobile first in email means the default markup is comfortable on a narrow screen:
- one logical reading column;
- body text at a readable size;
- buttons tall enough to tap;
- images that scale down;
- no horizontal scrolling; and
- no critical content hidden by CSS.
Desktop rules can widen padding, increase headings, and place simple sections side by side. If those rules disappear, the message should fall back to the useful mobile order.
Add the viewport and document basics
Include a viewport declaration and a complete document shell:
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="x-apple-disable-message-reformatting">
<title>Your monthly report</title>
</head>
<body style="margin:0;padding:0;background:#f1f5f9">
<!-- Email content -->
</body>
</html>
Reset body margin and padding inline. Do not rely on a web CSS reset surviving client sanitization.
Build fluid containers with tables
Presentation tables remain the most dependable structural tool for email. Add role="presentation" so assistive technology does not treat layout as data.
Use HTML width attributes as fallbacks and CSS for fluid behavior:
<table role="presentation" width="600"
style="width:100%;max-width:600px;background:#ffffff">
The attribute gives older clients a concrete width. The CSS allows the table to shrink on a narrower viewport.
Make images responsive
Give images an intrinsic width and a fluid style:
<img
src="https://example.com/report.jpg"
width="600"
alt="Chart showing a 14 percent increase in completed projects"
style="display:block;width:100%;max-width:600px;height:auto;border:0"
>
The display:block declaration removes the small baseline gap that inline images can create. Never place essential meaning only in an image; alt text should communicate its purpose when images are blocked.
For retina assets, upload an image at twice the displayed dimensions but keep the HTML width at the intended visual size. More guidance is in responsive email images.
Stack two columns safely
Columns are the point where responsive email gets difficult. A dependable pattern uses two table cells on desktop and changes them to block-level, full-width elements on small screens.
<style>
@media screen and (max-width: 600px) {
.stack-column {
display: block !important;
width: 100% !important;
}
}
</style>
<table role="presentation" width="100%">
<tr>
<td class="stack-column" width="50%" valign="top">First</td>
<td class="stack-column" width="50%" valign="top">Second</td>
</tr>
</table>
Put the more important item first in the source. That creates a logical mobile and screen-reader order without visual reordering tricks.
If the columns must reverse on mobile, use a tested direction-based pattern and confirm it in Outlook. Simpler content order is usually safer.
Use media queries selectively
Good uses for responsive email media queries include:
- reducing or increasing section padding;
- stacking columns;
- changing heading size;
- making buttons full width;
- centering elements on mobile; and
- hiding decorative details.
Do not use them to reveal the only CTA, show legal copy, or make an otherwise unusable layout readable.
@media screen and (max-width: 600px) {
.mobile-px-20 {
padding-left: 20px !important;
padding-right: 20px !important;
}
.mobile-button {
display: block !important;
width: 100% !important;
box-sizing: border-box !important;
}
}
Read what works in email media queries before adding more complex selectors.
Responsive Tailwind email
Tailwind can express a mobile-first design clearly:
<div class="px-5 py-8 sm:px-10 sm:py-12">
<h1 class="text-2xl leading-tight sm:text-3xl">Monthly report</h1>
<a class="mt-6 block rounded-lg bg-blue-600 px-6 py-3 text-center font-semibold text-white sm:inline-block">
View report
</a>
</div>
The unprefixed utilities are the baseline. A Tailwind email compiler must inline those base styles and preserve supported breakpoint rules. It may also rewrite div-based layout into tables.
See responsive Tailwind CSS emails for utility-specific patterns.
Typography that survives small screens
Use a conservative type system:
- 16px or similar for body copy;
- 24–36px for the main heading;
- 1.4–1.6 line height for paragraphs;
- short line lengths inside the content container; and
- explicit fallback font stacks.
Avoid shrinking text to fit. If a heading wraps awkwardly, improve the copy or layout instead of reducing it to an inaccessible size.
Mobile-friendly CTA buttons
A primary action should be a real link with generous padding and a clear label.
Keep the tap target comfortable, place enough space around it, and consider a full-width mobile style. For Outlook, use a table-backed button or a compiler that creates one.
The dedicated bulletproof email button guide covers Outlook-safe patterns.
Test responsive behavior
Check at least:
- narrow phone width;
- large phone width;
- tablet or narrow desktop;
- Gmail web and mobile;
- Outlook desktop and web;
- Apple Mail and iPhone Mail;
- images disabled;
- dark mode; and
- large text or zoom.
Test the delivered message, not only a browser resize. Email clients can rewrite the head, move CSS, and apply their own link or dark-mode styling.
Common responsive email mistakes
Fixed-width outer tables
A 600-pixel table with no fluid CSS causes horizontal scrolling on small screens.
Images without max-width
An oversized image can force the entire message wider than the viewport.
Desktop-first source order
When columns stack, the reading order may become confusing. Put content in the order that makes sense on mobile.
Too many breakpoint rules
Complex responsive systems are harder to debug and easier for clients to partially apply. Prefer a small number of meaningful rules.
Hidden essential content
Display utilities are not a safe way to deliver mutually exclusive critical sections. Every recipient should receive the required action and legal information.
Frequently asked questions
What width should a responsive email be?
A maximum around 600 pixels is a practical default, but it is not mandatory. Use a fluid container that can shrink below its maximum.
Do media queries work in every email client?
No. Support and sanitization differ. Make the no-media-query version complete and use queries for enhancement.
Should responsive emails use divs or tables?
Use presentation tables for important structure, or use a compiler that reliably converts higher-level source into tables. Divs remain useful for simple content grouping.
How many breakpoints do I need?
Often one mobile breakpoint is enough. Add another only when real content and client testing justify it.
Can I make an email responsive without media queries?
Yes. Fluid tables, max-width containers, flexible images, and naturally stacking content create a strong hybrid baseline.
Build the fallback first
The best responsive HTML email is not the one with the most breakpoints. It is the one that stays useful when the client ignores them.
Start with a narrow, readable message. Add fluid sizing, then use a small responsive layer for genuine improvements. Test the exported artifact across the clients that matter to your audience.
Share with friends