Updated · 8 min read
Mobile email design: 65% of opens are on a phone — design for that
The mobile-first argument was won five years ago. Yet a walk through any shipped email program turns up 600-pixel-wide two-column layouts, 14-point text, and CTAs that are 32 pixels tall. All of it works on desktop. None of it works on the 65% of opens that happen on a phone. The shift from desktop-first to mobile-first isn't about responsive tables — it's about which device you pretend the email is designed for while you're designing it.
Justin Williames
Founder, Orbit · 10+ years in lifecycle marketing
The numbers that set the constraint
Mobile email opens have been the majority since 2016 and the dominant share since 2019. Current industry averages put mobile at 60–70% of opens for consumer programs, 40–55% for B2B. Tablet is flat at 5–8%. Desktop is the remaining 25–40%.
Which means the modal user experience of your email is: held in one hand, scrolled with a thumb, read in 5–15 seconds on a 380–430 pixel wide screen with the screen at about half brightness, often while multitasking.
The email that's "fine" on mobile gets deleted. The email that's genuinely designed for mobile gets read. The difference is whether you picked the design constraints before or after the desktop version was signed off.
The six mobile-first rules
Rule 1: Single column below 600px. Multi-column layouts collapse into a narrow, cramped stack on mobile. Design single-column from the start and let desktop users get a slightly over-spaced version, rather than the other way around.
Rule 2: 16px minimum body text. 14-point text that looks correct on desktop is straining on mobile. iOS Safari actually bumps text smaller than 16px up to 16px to prevent zoom-on-focus; your 14px isn't saving space, the client is undoing your choice. Start at 16px.
Rule 3: 44×44 pixel minimum tap targets. Apple's Human Interface Guidelines specify this; Google's Material Design agrees. Any CTA smaller than this in any dimension produces misclicks and reduced conversion. Apply to buttons, links, and social icons alike.
Rule 4: CTA above the fold on a 667px tall viewport. Roughly the fold on an iPhone in portrait. Your primary CTA needs to be visible before the user scrolls, which in practice means within the first 400–500 vertical pixels of content.
Rule 5: Hero images under 600px tall. A hero that fills the screen on mobile means the user has to scroll before they see any text. Either keep the hero short, or overlay text on it.
Rule 6: One primary CTA per email. Two CTAs is a desktop pattern; on mobile, two side-by-side buttons become one cramped and one ignored. Pick the primary action; if you need a secondary, make it a text link below.
Preheader and subject on mobile
Mobile inbox displays ~40 characters of subject and ~40 characters of preheader before truncating. Your subject-preheader pair has ~80 characters of inbox real estate on mobile — less than any desktop client.
Design for the first 40 characters of each carrying the full message. Desktop users will see the longer versions; mobile users need the truncated version to work alone.
The subject line anatomy guide and the preheader guide both cover the 40-character mobile constraint.
What desktop-first design gets wrong
,
The opposite failure — designing only for mobile and ignoring desktop — is rarer and less damaging. Mobile constraints force simpler, shorter emails, which generally serve desktop users equally well. Over-designing for desktop is the more common mistake.
Testing on actual devices
Litmus and Email on Acid provide screenshot previews across clients, but nothing replaces viewing the email on your own phone before pressing send. Specific things to check on a real device:
• Can you read the subject and preheader at the natural viewing distance?
• Is the primary CTA tappable without scrolling, and tappable without zooming?
• Does the body text flow naturally or do you need to zoom?
• Do images load at reasonable speed on mobile data (not just on your home wifi)?
• Is the unsubscribe link reachable without frustration? A difficult-to-unsubscribe mobile flow is a major source of spam complaints.
The unsubscribe guide covers the mobile unsubscribe flow specifically.
treats a real-device mobile check as a default step in template QA — the Litmus preview is the screen, the phone check is the experience.
Frequently asked questions
- Why is mobile-first still an argument in 2026?
- Because most teams have desktop design tools (Figma, Sketch) optimised for 1440px canvases, so the default workflow is to design desktop first. Mobile-first is a workflow discipline, not a technology one — it requires starting the design in a 375-pixel wide frame and accepting that desktop is the adaptation, not vice versa.
- What's the minimum width for email?
- 375px covers the iPhone SE/mini; 360px covers smaller Android devices. Design for 360–430px as the primary canvas. Anything narrower than 360px is a vanishingly small portion of the audience and not worth optimising for.
- How do I handle multi-column layouts on mobile?
- Single column is safest. If you need multi-column on desktop, use media queries to stack columns below 600px. But ask first: does the multi-column serve the user or just fit more content on desktop? Usually the latter, and the content would be better as a single-column flow regardless.
- What image sizes should I use?
- Design at 2× the target display size for retina sharpness (so a 600px wide hero image ships as a 1200px image). Keep total email weight under 150KB for fast loading on mobile data. Compress aggressively; WebP where supported, PNG or JPEG fallback otherwise.
- Should I use dark-mode variants?
- Yes, if you have the engineering budget — Apple Mail (dominant on iOS) honours prefers-color-scheme. See the dark mode design guide. For programs without the budget, use defensive-design rules (off-white backgrounds, near-black text) so the email is at least acceptable in all render modes.
- Does accelerated mobile email (AMP) still matter?
- In 2026, AMP for Email is supported by Gmail and Yahoo but uptake is niche. For most programs, it's not worth the engineering cost. If you're sending a lot of dynamic content where real-time data (inventory, pricing) changes between send and open, AMP can help. Otherwise, static HTML is sufficient.
Related guides
Browse all →Email dark mode: the four render modes and how to not break any of them
Dark mode in email isn't one thing — it's four different render behaviours depending on the client. Design without knowing which mode you're hitting and your emails will look broken to 40% of your audience. Here's what each client does.
Preheader text: the second subject line most programs ignore
Preheader text is the snippet shown next to the subject line in the inbox preview. Done well, it doubles your hook. Done badly, it says 'View this email in your browser'. Here's how to write preheaders that earn the open.
Email accessibility: the seven rules that make your emails readable by everyone
Email accessibility isn't a compliance tax — it's the difference between reaching 100% of your audience and the 85% who have easy sight, steady hands, and full-volume screens. Here are the seven rules that cover 90% of what actually matters.
Transactional email anatomy: the five sections every transactional needs
Transactional emails get opened at 3–5× the rate of marketing and carry more brand signal per send. Most programs treat them as ops artefacts and miss the leverage. Here's the five-section template that works for every transactional type.
Brand voice in lifecycle: how to sound like you — not the generic SaaS CRM voice
Lifecycle emails drift toward a generic 'polished SaaS CRM voice' because it's the default pattern in every template library and every agency deliverable. Here's how to actually write in your brand's voice across an entire lifecycle program.
The email copywriting pyramid: write for the 5-second reader first
Most email recipients read for 5 seconds before deciding to engage or delete. The email has to work at that reading depth and still reward a longer read. The inverted pyramid structure — lead with conclusion — is how to do it.
Found this useful? Share it with your team.