Email design for mobile: layouts that survive phones

Email is predominantly read on phones, and for most consumer audiences in India the margin is not close. But the useful figure here is not an industry average — it is your own. Every email platform reports the client and device breakdown for your sends, and that report is a first-party fact about your list rather than an estimate about somebody else's.

Check it before making design decisions, because the answer changes them. A list of procurement managers read on desktop Outlook during working hours has different constraints from a list of retail customers reading on Android phones in the evening, and the second group is far more common for a small business selling to consumers.

The reason this matters more in email than on the web is that you cannot fix it later. A website can be adjusted after you notice a problem and every visitor sees the correction. A sent email is fixed forever in thousands of mailboxes, rendering the way it renders, and the only remedy is to send another one.

Email rendering is the least consistent environment in modern software. Clients differ in which CSS they support, some strip a style block in the head, some ignore media queries, and one widely used desktop client renders HTML through a word-processing engine rather than a browser engine.

The practical consequence is that a responsive multi-column layout does not degrade predictably. Where media queries are honoured it stacks neatly; where they are stripped, three columns designed for a wide screen are squeezed into a phone's width, producing 8-point text and horizontal scrolling. You cannot know in advance which recipients get which.

A single-column layout avoids the entire problem, because it needs no rearranging to fit a narrow screen — it is already narrow. Constrain the overall width to around 600 pixels so it also looks deliberate on desktop, build the structure with tables and inline styles rather than modern layout CSS, and treat media queries as an enhancement for clients that support them rather than as the mechanism the design depends on.

A link that is easy to click with a mouse can be genuinely difficult to hit with a thumb. Both major platform design guidelines put numbers on this: Apple's Human Interface Guidelines recommend a minimum tap target of 44 by 44 points, and Google's Material guidance uses 48 by 48 density-independent pixels. Those are minimums for a target the user is expected to hit reliably.

A line of body text with three links in it fails that standard in both directions — each target is about 16 pixels tall, and they are adjacent, so a near miss activates the wrong one. This is why the primary action should be a button with real padding around the label rather than a text link sitting in a paragraph.

Stacked links need vertical separation for the same reason. A footer with six links on consecutive lines is a set of mistakes waiting to happen, and adding line height or padding between them costs nothing. The general rule: anything you actually want tapped gets space around it, and anything crowded should not be load-bearing.

Small text does not just look small on a phone; it can break your layout. iOS enforces a minimum legible size and will scale text up when a message specifies something below it, which means a template designed at 11 pixels does not render as tiny text — it renders as text at a size you did not choose, reflowing everything around it.

Setting body text at around 16 pixels avoids that intervention and is also simply readable. Give it a line height around 1.4 to 1.5, because tight leading is harder to read on a small screen than on a large one.

Left-align body copy. Centred text is fine for a single short line such as a heading, and it becomes progressively harder to read as it gets longer, because the eye has to find a new starting position on every line. A centred paragraph of four lines is a common and entirely avoidable choice.

And keep contrast high. Light grey on white looks refined on a calibrated monitor indoors and disappears on a phone held outdoors, which is a substantial share of when your mail is actually read.

Many recipients see your email without images at least initially — blocked by default in some clients, delayed on a slow connection, or stripped by a gateway. If the offer, the date or the call to action exists only inside an image, those readers receive a blank email.

So keep every load-bearing element as real text: headline, key facts, and the button. Use images for what images are for — the product, the room, the food — and give every one of them alt text, which is both what a screen reader announces and what a recipient with images off will read in its place.

Two further practicalities. Export at roughly twice the display width for sharp rendering on high-density screens, but keep file sizes sane, because a message weighing several megabytes loads slowly on mobile data and some clients truncate long messages entirely. And check dark mode: several clients invert colours, which can turn dark text on a transparent background into dark text on a dark background, and can make a logo saved as a transparent PNG vanish completely.

Keep a seed list of real addresses on real devices covering the clients your own analytics say your audience uses — typically an iPhone, an Android phone, Gmail in a browser, and whichever desktop client your business customers use. Send the actual campaign to it, not a preview render, because previews are generated by a rendering engine and the failures you care about are the ones caused by a specific client's quirks.

On each device check five things: does it read as a single column, is the primary action obvious without scrolling far, does it make sense with images blocked, does dark mode do anything unpleasant, and can you hit every link with a thumb.

Then check it with the system font size increased, since a meaningful share of readers use larger text and the layout should survive it.

Build in one deliberate pause before sending: open the seed copy and click every link. Broken links are the most common defect in sent email and the only one that is entirely avoidable by looking.