What this is for#
More than 60% of email opens happen on mobile devices (per most published benchmarks; even higher in B2C). Designing the desktop version first then "checking mobile" gives you a desktop email that's tolerable on mobile. Designing mobile-first gives you a mobile email that looks great on desktop too.
This guide walks the 6 principles that produce mobile-friendly templates from the start.
The 6 principles#
1. Single-column layout (always)#
Why: mobile screens are typically 360-440px wide. A 2-column layout at this width forces text to 180-220px columns = 4-6 words per line = brutal to read. Stack everything vertically.
For "two-column on desktop, stacked on mobile" sections, use the stack-on-mobile pattern:
<!-- Desktop: 2 columns side-by-side -->
<!-- Mobile: each column 100% width, stacked vertically -->
<table role="presentation" width="600" cellpadding="0" cellspacing="0" border="0">
<tr>
<td class="stack" valign="top" width="50%" style="padding: 20px;">
Left content
</td>
<td class="stack" valign="top" width="50%" style="padding: 20px;">
Right content
</td>
</tr>
</table>
<style>
@media only screen and (max-width: 600px) {
.stack {
display: block !important;
width: 100% !important;
}
}
</style>
The @media query flips td elements to display: block on mobile, which makes them stack.
2. 16px minimum body font#
Why: smaller than 16px on a 4-inch screen is genuinely hard to read. Apple's iOS design guidelines specifically recommend 16px as the minimum for sustained reading; Google's Material Design says 14-16px minimum. Below that, recipients zoom in (causing horizontal-scroll layout damage) or just close the email.
<!-- Body text -->
<p style="font-family: Arial, sans-serif; font-size: 16px; line-height: 1.5; color: #333;">
<!-- Headlines -->
<h1 style="font-family: Arial, sans-serif; font-size: 24px; line-height: 1.3; color: #111;">
In an @media (max-width: 600px) block, bump body to 18px if you want even more headroom:
@media only screen and (max-width: 600px) {
.mobile-body { font-size: 18px !important; }
}
Don't go below 14px for legal disclaimers / unsubscribe footers — even if visually they "look like fine print", the actual fine print becomes invisible on mobile.
3. 44×44 px minimum tap targets#
Why: Apple's Human Interface Guidelines specify 44×44 pt as the minimum tap target size — anything smaller produces frustrating mis-taps. Google's Material Design uses 48dp (similar). Tappable elements smaller than that fail accessibility checks too.
For buttons + CTA links:
<table role="presentation" cellpadding="0" cellspacing="0" border="0">
<tr>
<td bgcolor="#0066CC" style="padding: 16px 32px; border-radius: 8px;">
<a href="https://..." style="color: #ffffff; text-decoration: none;
font-family: Arial, sans-serif;
font-size: 16px; font-weight: bold;
display: inline-block;
min-height: 44px; line-height: 44px;">
Get started
</a>
</td>
</tr>
</table>
The combination of padding: 16px 32px + font-size: 16px typically produces a button ~52px tall × at-least-44px wide = comfortably tappable.
For inline text links (e.g., "Learn more →"), wrap them with spacing:
<p style="font-size: 16px; line-height: 1.8; padding: 8px 0;">
Read more about <a href="..." style="padding: 4px 0;">our pricing</a> and how we compare.
</p>
4. 600px max width with responsive scaling#
Why: 600px is the de-facto email standard. Wider tables either crop in Outlook desktop or trigger horizontal scroll in Gmail web. On mobile, the 600px table should scale to full width.
<table class="mobile-fluid" role="presentation" width="600"
cellpadding="0" cellspacing="0" border="0" align="center">
...
</table>
<style>
@media only screen and (max-width: 600px) {
.mobile-fluid {
width: 100% !important;
max-width: 100% !important;
}
}
</style>
5. Finger-friendly padding (20px+ on mobile)#
Why: content butted against the screen edges feels claustrophobic on mobile. 20-30px padding on all sides gives reading comfort.
<td class="mobile-pad" style="padding: 40px;">
Content
</td>
<style>
@media only screen and (max-width: 600px) {
.mobile-pad { padding: 24px !important; }
}
</style>
Don't let mobile padding drop below 16px — content needs breathing room.
6. Full-width images that scale#
Why: an image fixed at width="600" will overflow a 360px-wide mobile screen, causing horizontal scroll. Make images responsive:
<img src="hero.png"
alt="Smiling barista handing coffee to customer"
width="600" height="300"
style="display: block;
width: 100%;
max-width: 600px;
height: auto;" />
width="600" (attribute, not style) — for Outlook desktop, which doesn't fully respect CSS widthwidth: 100%; max-width: 600px; (style) — scales down on mobile, caps at 600px on desktopheight: auto; — preserves aspect ratiodisplay: block; — removes the 4px bottom gap browsers add to inline images
For decorative icons (small images): use fixed width="40" height="40" style="width: 40px; height: 40px;" — don't scale.
Worked example — mobile-first responsive template#
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="color-scheme" content="light dark">
<style>
@media only screen and (max-width: 600px) {
.mobile-fluid { width: 100% !important; max-width: 100% !important; }
.mobile-pad { padding: 24px !important; }
.mobile-stack { display: block !important; width: 100% !important; }
.mobile-text-big { font-size: 18px !important; }
}
</style>
</head>
<body style="margin: 0; padding: 0; background-color: #f4f4f4;">
<table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">
<tr>
<td align="center" style="padding: 20px;">
<table class="mobile-fluid" role="presentation" width="600"
cellpadding="0" cellspacing="0" border="0"
style="background-color: #ffffff; border-radius: 8px;">
<!-- Header -->
<tr>
<td class="mobile-pad" style="padding: 40px 40px 20px;">
<img src="https://cdn.example.com/logo.png" alt="Acme"
width="180" height="40"
style="display: block; width: 180px; height: 40px;">
</td>
</tr>
<!-- Hero image -->
<tr>
<td>
<img src="https://cdn.example.com/hero.jpg" alt="Hero alt text"
width="600" height="300"
style="display: block; width: 100%; max-width: 600px; height: auto;">
</td>
</tr>
<!-- Body -->
<tr>
<td class="mobile-pad" style="padding: 40px;">
<h1 style="font-family: Arial, sans-serif; font-size: 24px;
line-height: 1.3; color: #111; margin: 0 0 20px;">
Hi {FIRST_NAME}
</h1>
<p class="mobile-text-big"
style="font-family: Arial, sans-serif; font-size: 16px;
line-height: 1.5; color: #444;">
Body content with comfortable 16px font, 1.5 line-height.
</p>
<!-- 44px-min tap target CTA -->
<table role="presentation" cellpadding="0" cellspacing="0" border="0"
style="margin: 30px 0;">
<tr>
<td bgcolor="#0066CC" style="padding: 16px 32px; border-radius: 8px;">
<a href="https://example.com/cta"
style="color: #ffffff; text-decoration: none;
font-family: Arial, sans-serif; font-size: 16px;
font-weight: bold; display: inline-block;
min-height: 44px; line-height: 44px;">
Get started
</a>
</td>
</tr>
</table>
</td>
</tr>
<!-- Stacked footer columns -->
<tr>
<td>
<table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">
<tr>
<td class="mobile-stack" valign="top" width="50%" style="padding: 20px 40px;">
<p style="margin: 0; font-family: Arial, sans-serif; font-size: 14px; color: #666;">
Acme HQ<br>123 Main St<br>San Francisco, CA 94102
</p>
</td>
<td class="mobile-stack" valign="top" width="50%"
style="padding: 20px 40px; text-align: right;">
<p style="margin: 0; font-family: Arial, sans-serif; font-size: 14px; color: #666;">
<a href="{UNSUBSCRIBE_URL}" style="color: #0066CC;">Unsubscribe</a>
</p>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
</table>
</body>
</html>
Testing protocol#
- Send a test to yourself on at least: iPhone (Apple Mail), Android (Gmail app), iPad (Apple Mail), and one desktop browser (Gmail web)
- Resize browser windows — open the email on desktop Gmail, then resize the window from 600px down to 320px while watching how it adapts
- Use Litmus / Email on Acid for cross-client at-scale verification
- Check tap-target sizes physically — tap each link/button with your thumb on the actual mobile device, not just visual inspection
The "send to your own phone" test catches 80% of mobile issues. Spend the 5 minutes.
Common failures#
| What you see |
Likely cause |
Fix |
| Horizontal scroll on mobile |
Image or table wider than screen |
Use width: 100%; max-width: 600px; on images; use mobile-fluid class on outer table |
| Text too small to read on mobile |
Body < 16px |
Bump to 16px; or 18px on mobile via @media |
| Mis-taps on CTAs |
Buttons < 44×44px |
Increase padding + line-height per Principle 3 |
| Tested desktop, mobile broken |
Designed desktop-first |
Re-design starting from mobile constraints |
| Hero image cropped on mobile |
Fixed-width attribute without max-width: 100% style |
Add both width attribute (Outlook) AND CSS width style (everyone else) |
| Stacked columns don't stack |
display: block not in @media query |
Verify the @media (max-width: 600px) block exists + !important on the property |
| Padding looks tight on small phones |
Mobile-only padding > screen width minus content |
Use 20-24px mobile padding, never less than 16px |
FAQ#
Can I just use AcelleMail's drag-and-drop builder? Yes — recent versions generate responsive mobile-friendly HTML automatically. Use the raw HTML editor only when you need precise control (e.g., porting an externally-designed template).
My audience is 90% desktop B2B. Do I still need mobile-first? Less urgent — but mobile share is rising in B2B too. Mobile-first design also forces clearer hierarchy, which benefits desktop. Worth doing even at low mobile percentages.
What about email-on-watch (Apple Watch)? Mostly text-only rendering; recipients almost never act on watch — they triage and read in detail later on phone. Don't optimize for watch specifically.
Tablet design — separate breakpoint? Most tablets (iPad, Galaxy Tab) render emails at desktop sizes. Don't add a tablet-specific breakpoint; design for mobile + desktop and tablets handle themselves.
AMP for Email mobile? Gmail supports AMP for Email; the responsive primitives are stronger. Niche; not bundled with AcelleMail.
Related articles#
