Mobile Email Best Practices: Designing Emails That Work on Small Screens

Mobile email best practices are the layout, typography, image, tap-target and preview-text decisions that keep an email readable and tappable on a phone. Two things make mobile different from desktop: a narrow viewport — roughly 320 to 430 CSS pixels wide on most phones — and a finger instead of a cursor. Get those two constraints right and most of the rest follows.

This guide covers what to decide, how responsive email actually works, a worked rebuild of a typical promo, the mistakes that show up again and again, and a checklist you can run before every send. It sits alongside the broader email marketing best practices checklist — mobile is one cluster within it, not a separate discipline.

What Mobile Email Best Practices Actually Cover

"Mobile friendly email" and "responsive email" get used interchangeably, but they are not the same thing. Responsive email is a technical approach: the layout adapts to the viewport using media queries or fluid widths. Mobile friendly is the broader outcome — the email is readable, tappable and fast to load on a phone, regardless of how it was built.

That distinction matters because a technically responsive email can still be a bad mobile email. If the body text is 12px, the buttons are 30px tall, the hero image is 900KB and the preview text is empty, the media queries did their job and the reader still bounces.

So the practical scope is wider than CSS. It includes:

• Layout — how content reflows and what appears in the first screenful.
• Typography — font sizes, line height and line length at phone width.
• Tap targets — button size, padding and spacing between links.
• Images — file weight, dimensions, and what happens when they are blocked.
• Preview text and subject line — the part of the email most readers see first.

Everything below is a decision inside one of those five buckets.

How Responsive Email Works Under the Hood

You do not need to write the code, but you do need to know what to ask for — and what to check when something looks wrong.

Single-column stacking. A desktop email is often built on a 600px-wide table. On a phone, that layout either scales down proportionally (everything gets smaller, including text) or reflows into a single column (content stays the same size and stacks vertically). Reflowing is what you want. A two-column product row should become two stacked rows below roughly 480px.

Fluid images. An image with max-width: 100% and height: auto shrinks with its container instead of overflowing. Without it, a 600px image forces horizontal scrolling on a 390px screen.

Media queries. These are the @media (max-width: 480px) { ... } blocks that change styles at specific widths. Common breakpoints sit around 480px and 600px.

Hybrid or "spongy" layouts. Some clients strip or partially ignore <style> blocks, which kills media queries. Hybrid layouts use inline styles, max-width and table tricks so the email stacks correctly even without media query support.

Client quirks. Gmail's app and Outlook mobile apply their own rendering rules — Gmail historically stripped <style> in some contexts, and both handle dark mode and image scaling differently. This is why testing on real devices beats reasoning about it.

The Decisions That Matter Most

Layout: One Column, Left-Aligned, Short Blocks

Use a single-column body. Keep the desktop max width around 600px and let it collapse to full width on mobile. Avoid side-by-side columns for anything the reader has to read in order — two columns work for two comparable products, not for a paragraph and its continuation.

Keep paragraphs to two or three sentences. Put the offer, the price and the primary button in the first screenful, because the first scroll decides whether the rest gets read at all.

If you are working in a visual block editor with hero, product and column blocks, you can control this without hand-coding tables — the Mailerflow editor uses reusable blocks and templates, which also means a layout you have already tested on mobile can be reused rather than rebuilt.

Font Sizes and Line Length

Concrete numbers to design against:

Two traps here. First, images of text: they do not scale with the reader's font settings, they blur on high-density screens, and screen readers cannot read them. Use live text. Second, iOS auto-scaling: some clients enlarge text below a certain size, which can break a layout that depended on 13px labels staying 13px.

Tap Targets and Spacing

Apple's guidance puts the minimum comfortable tap target at 44x44 CSS pixels. Treat that as the floor, not the goal — a 48px button with 12px of padding reads better and is easier to hit.

Make the entire button a link, not just the label. And leave at least 10px of vertical space between adjacent links; two links stacked with no gap is how the wrong one gets tapped. If a paragraph contains three inline links, consider whether one button would serve the reader better.

Images, Weight and Alt Text

Aim to keep total email weight well under 1MB. Compress every image, export 2x assets for retina screens but cap the display dimensions, and always set explicit width and height attributes so the layout does not jump while images load.

Write alt text that carries the message. Many readers see images blocked by default, and some see them blocked permanently. If your hero image is the only place the offer appears, those readers get nothing — repeat the offer in live text.

Preview Text and Subject Lines on a Phone

A phone inbox shows roughly 30–40 characters of subject line and 40–90 characters of preview text, depending on the client and device. Front-load the value in the first 30 characters of the subject.

Write preview text that extends the subject rather than repeating it. The classic failure is leaving it empty, so the client pulls the first line of body copy — which is usually "View this email in your browser."

If you want a starting point rather than a blank field, Mailerflow's AI email builder drafts subject lines and preview text from a description of the email; you still edit them, but you are editing instead of staring.

A Worked Example: Rebuilding a Two-Column Promo

Here is an illustrative rebuild — not a customer story, just a design walkthrough of a common pattern.

Before: a 600px fixed-width table with a hero image, two product cards side by side, and a "Shop now" button. Body text 12px. Button 30px tall. No alt text. Preview text empty. Subject line: "Our biggest sale of the season is here."

On a 390px phone, this scales down to roughly 65% — body text renders near 8px, the two product cards are each about 180px wide with text wrapping every three words, and the button is a 20px-tall sliver. The subject line truncates at "Our biggest sale of the…" and the preview line reads "View this email in your browser."

After: single column, full width on mobile, 600px max on desktop. Body text 16px, line height 1.5. Products stacked, each with a 2x image, explicit dimensions, and alt text naming the product and price. Button 48px tall, full-width on mobile, with 12px of padding around it. Preview text: "Ends tonight — 20% off everything, no code needed." Subject line: "20% off ends tonight."

Same offer, same list, same send time. The difference is that on the phone, the reader can read the price, see the product, and hit the button without zooming.

The subject line change is worth noting separately. "Our biggest sale of the season is here" spends its first 30 characters on framing. "20% off ends tonight" spends them on the offer and the deadline.

Common Mistakes and How to Avoid Them

• Body text under 14px. It looks fine on your monitor and unreadable on a phone. Set 16px as the default and only go lower for legal footnotes.
• Image-only emails. A single flat image of your whole design cannot be read with images off, cannot be read by a screen reader, and cannot reflow. Build with live text and use images as support.
• Missing alt text. Every meaningful image needs it. Decorative images should have empty alt attributes so screen readers skip them.
• Buttons under 44px. Small buttons get missed, and a missed tap is a lost click. Size the button, not the label.
• Links crammed together. Add vertical spacing between adjacent links, or convert one of them into a button.
• Fixed-width layouts. Anything wider than the viewport forces horizontal scrolling. Use fluid widths and let the layout reflow.
• Heavy images. A 2MB hero image is a slow load on mobile data. Compress, resize and check total weight.
• Empty preview text. The client fills the gap with whatever comes first in the body, which is rarely what you would have chosen.
• Testing in one client only. Gmail app, Apple Mail and Outlook mobile render differently. Test all three at minimum.

Pre-Send Mobile Test Checklist

Run this before every campaign. It takes a few minutes and catches most of what goes wrong.

1. View the email at 320px and 430px widths.
2. Check the first screenful: is the offer and the primary button visible without scrolling?
3. Confirm body text renders at 16px or larger.
4. Tap every button and link with a thumb, not a cursor.
5. Verify buttons are at least 44px tall with space around them.
6. Turn images off and read the email — does it still make sense?
7. Check every meaningful image has descriptive alt text.
8. Read the subject line and preview text as they appear in Gmail mobile.
9. Check total email weight (aim well under 1MB).
10. Test in Gmail app, Apple Mail and Outlook mobile.
11. Check dark mode if your design uses light backgrounds.
12. Confirm no horizontal scrolling at 320px.

FAQ

What width should a mobile email be?

Design for a fluid layout that fills the viewport, with a desktop max width around 600px. The narrowest phone you should support renders at about 320 CSS pixels, so test there. Avoid fixed pixel widths on any container that holds text.

Do I need a separate mobile version of my email?

No. A single responsive email that reflows into one column is the standard approach and is far easier to maintain than two templates. A separate mobile version doubles your testing surface and drifts out of sync quickly.

How long should a mobile subject line be?

Front-load the value in the first 30 characters, since that is roughly what a phone inbox displays before truncating. Longer subject lines are fine if the important part comes first — just do not bury the offer at character 45.

Why does my email look different in Gmail?

Gmail's app applies its own rendering rules, including how it handles <style> blocks, image scaling and dark mode. That is why hybrid layouts and inline styles exist, and why testing in the actual Gmail app matters more than testing in a desktop preview.

How many images is too many?

There is no fixed number, but weight is the real constraint: keep the total email under 1MB and compress every asset. A practical rule is that the email should still communicate its offer with images turned off, which naturally limits how much you lean on them.

If you would rather start from a layout that already handles stacking, tap targets and preview text, Mailerflow's AI builder generates a complete responsive design from a description, and you can adjust it in the visual block editor. Create your first campaign free — the Free plan includes 2,500 contacts and 10,000 emails a month, and paid plans start at $14.90/month with unlimited emails.