Emails that render well everywhere are simple: a single main column, real text, tested colours, images with fallback text and one clear action. The constraint is that you do not control the viewing environment. Each mail app handles HTML and CSS differently, so the safest design is one that still works when parts of it are stripped away. Treat testing in real clients as part of the design job, not an afterthought.
How email differs from web design
A web page runs in a browser you can reasonably predict. An email is displayed by whichever app the recipient uses, including web mail, phone apps and desktop clients, each with its own rendering rules. Features you rely on for websites may be partly or wholly unsupported.
Google’s documentation for Gmail shows the pattern. Gmail supports embedded style blocks and many common properties, but only a subset of selectors (class, element and ID), and it may ignore unsupported properties and selectors, so Google advises testing. Media queries are supported for screen width, orientation and resolution, which makes responsive layouts possible (Google for Developers). Other clients differ, which is why cross-client testing matters.
Layout rules that survive
- One main column. A single column of around 600 pixels wide is a common convention that scales down naturally on phones. Treat the exact width as a starting point rather than a rule.
- Stack on small screens. If you use columns, make them collapse to a single column through a supported media query, and test the fallback where media queries are ignored.
- Use tables for structure where compatibility matters, as many email clients are less reliable with modern layout techniques. Check your email tool’s templates, which usually handle this for you.
- Keep it short. One message, one primary button.
- Make tap targets generous. Buttons and links need room for a thumb.
- Put the point first. Preview text and the first lines often decide whether the email is read.
Accessibility basics
Accessible emails are also more robust emails. WCAG 2.2 gives measurable targets.
- Contrast. Success Criterion 1.4.3 (Level AA) asks for a contrast ratio of at least 4.5:1 for standard text and 3:1 for large text, where large means at least 18 point or 14 point bold, and the ratios should not be rounded (W3C).
- Structure. Success Criterion 1.3.1 asks that information, structure and relationships conveyed visually can also be determined by software or exist as text, for example real headings, lists and table markup rather than bold text or spacing standing in for them (W3C).
- Real text. Keep key content, offers and dates as live text, not baked into images.
- Alt text. Describe meaningful images and leave decorative ones empty.
- Link wording. “Read the guide” is clearer than “click here”.
- Language. Declare the language of the email where your tool allows it.
- Plain-text version. Include one, since some readers and clients rely on it.
See using AI to improve accessibility for how tools can help draft alt text and plain-language copy, with human review.
Images and weight
Many recipients will see your email with images blocked at first, so the message should still make sense without them. Design with these points in mind:
- Put the main message and call to action in text.
- Provide alt text that carries the meaning of each key image.
- Compress images and size them for their display width, using the thinking in responsive images for performance.
- Avoid a single large image as the whole email.
- Use background colours behind text so it remains readable if the image fails.
Dark mode
Many mail apps offer a dark display setting, and they apply it in different ways: some leave your colours alone, some invert them partially, and some fully. The consequence is that your design can look different from what you approved, and the behaviour is not uniform across clients.
Practical steps:
- Avoid pure reliance on a white background or on light-coloured text on a white box that might not be inverted.
- Check contrast in both appearances using the same 4.5:1 and 3:1 targets above.
- Provide logos that work on light and dark backgrounds, for example a version with a clear edge or a neutral surround, rather than a dark logo on a transparent background that vanishes. Format guidance is in logo file formats explained.
- Test in real clients in both modes and fix the worst problems rather than chasing every one.
- Do not assume support for dark-mode-specific CSS, which varies by client. Check each client’s current documentation.
The broader trade-offs of supporting dark appearance are discussed in dark mode on websites.
A testing checklist
- Sent test to at least one webmail and one phone app
- Viewed with images off
- Viewed in dark mode where available
- All links work and carry meaningful wording
- Contrast checked for text and buttons
- Alt text present on meaningful images
- Plain-text version included
- Unsubscribe link visible and working
Remember that the rules on consent and unsubscribing apply regardless of design. Poor design cannot be excused, and neither can a hidden unsubscribe link.
Limitations
This guide gives principles, not a compatibility table. Client behaviour changes, and the only reliable check is testing in the clients your audience actually uses. Use your own list’s data to decide which clients to prioritise.
Where Radiance Impact fits
Radiance Impact’s Studio and Growth divisions work on creative production and campaigns, and the Technology division builds websites and automation that send emails. For help designing campaign templates, see /studio or /growth and contact us through /contact.
Sources
- Gmail CSS support, Google for Developers
- Understanding SC 1.4.3: Contrast (Minimum), W3C
- Understanding SC 1.3.1: Info and Relationships, W3C
