Email rendering across clients: testing and compatibility
You design an email. It looks sharp in the preview. Then you open it in Outlook and the layout is broken. Gmail stripped your styles. Yahoo shifted the margins. Apple Mail rendered it perfectly, but in dark mode your logo disappeared into the background. This is not a bug in your code. This is how email clients work.
Why the same HTML looks different everywhere
Web browsers share rendering standards. Chrome, Firefox, Safari follow the same CSS spec, give or take minor edge cases. Email clients do not. There is no shared standard for how email HTML should be rendered. Each client applies its own rules, strips certain properties, rewrites others, and adds its own styles on top of yours before the user ever sees the message.
Outlook on Windows uses Microsoft Word's rendering engine to display HTML emails. Not a browser engine. Word. That means no support for flexbox, no grid, limited background images, and unpredictable margin behavior. Gmail strips the entire <style> block from <head> if the HTML exceeds 102 KB, and rewrites class names even when it keeps them. Apple Mail supports nearly all modern CSS but aggressively auto-inverts colors in dark mode. Yandex.Mail and Mail.ru each have their own sanitization pipelines with restrictions on max-width, positioning, and image handling.
The result: a single email can look four different ways in four different inboxes. If you only tested in one client before sending, three out of four recipients saw something you never intended.
What breaks where: a field guide
Outlook (Windows). The Word engine does not understand border-radius, so rounded buttons become rectangles. Background images require VML markup. Padding on <div> elements is often ignored — use table cells instead. Line-height calculations differ from every other client, which shifts vertical spacing. Conditional comments <!--[if mso]> are the standard workaround: they inject Outlook-specific HTML that other clients ignore.
Gmail. All class names get prefixed, so if your CSS relies on descendant selectors or complex specificity, it may break. Media queries work in most Gmail interfaces now, but not reliably in the Android app for non-IMAP accounts. The 102 KB limit on HTML size is a hard boundary. Exceed it, and Gmail clips the message with a "View entire message" link. Most recipients will not click that link.
Apple Mail. The most forgiving client. It supports web fonts, media queries, CSS animations, and prefers-color-scheme. The catch is dark mode. Apple Mail automatically inverts light backgrounds to dark and dark text to light. If your design uses mid-range colors or images with transparent backgrounds against an assumed-white canvas, the automatic inversion can produce unreadable combinations.
Yandex.Mail and Mail.ru. Both popular in Russia and CIS. Both have their own sanitization pipelines that strip certain CSS properties. Yandex handles media queries but sometimes overrides font sizes in its mobile app. Mail.ru ignores max-width on <div> elements but respects it on table cells. If your audience is Russian-speaking, these two clients are not optional to test.
How to test before you send
There are three approaches, and they work best in combination.
Automated preview services. Litmus and Email on Acid take your HTML, render it across 90+ email clients and devices, and return screenshots. You see exactly what your subscribers will see in Gmail on Android, Outlook 2019 on Windows, Apple Mail on iPhone 15, Samsung Mail, and dozens more. These services cost money — typically $80–150 per month — but they compress what would take hours of manual testing into minutes. For teams that send regularly, they pay for themselves.
Manual testing on real accounts. Create mailboxes on Gmail, Outlook.com, Yahoo, Yandex, Mail.ru, and iCloud. Send yourself a test email. Open it on desktop and mobile. Toggle dark mode. Check with images disabled. This is slower than Litmus but free, and it gives you the real experience rather than a static screenshot. The minimum viable set: Gmail (web), Outlook (Windows desktop), Apple Mail (iOS), and one Russian client if your audience includes that geography.
Code-level validation. Tools like HTMLHint with email-specific rules, or the Parcel email editor, catch common issues before you even send the test. Missing alt attributes, unsupported CSS properties, HTML weight over 102 KB, missing inline styles. These tools do not replace visual testing but they eliminate the obvious problems early.
Common rendering problems and how to fix them
Broken layout in Outlook. Use tables for structure, not div-based grids. The outer table at 100% width sets the background; the inner table at 600px max-width holds the content. Wrap columns in conditional comments for Outlook and use display: inline-block divs for modern clients. This hybrid approach renders correctly across the board.
Clipped message in Gmail. Keep total HTML under 102 KB. Minify your markup. Remove unnecessary comments and whitespace. If your email includes long product lists, cut the number of items and link to the website for the full catalog.
Invisible logo in dark mode. Use PNG with transparent background and add a thin white or light-colored stroke around the logo edges. Or prepare two versions of the logo and swap them via @media (prefers-color-scheme: dark). For clients that do not support the media query, the light version shows by default, so make it the one that works on both backgrounds.
Images blocked by default. Many corporate Outlook installations and some webmail clients block images until the user clicks "Show images." Your email should be readable without any images at all. Use descriptive alt text. Set background colors on image containers so the layout does not collapse. Never put critical information only in an image.
Font rendering differences. Web fonts work in Apple Mail, iOS Mail, and Samsung Mail. Gmail and Outlook ignore them. Design your email around system fonts — Arial, Helvetica, Georgia — and treat web fonts as progressive enhancement. Match the fallback font metrics to the primary font so the layout does not shift for recipients whose clients drop the web font.
Rendering is half the problem. Delivery is the other half.
You can test rendering in every client on earth and still fail if the email never arrives. A perfectly designed message that lands in the spam folder is invisible. One of the primary reasons emails go to spam is sending to invalid addresses. High bounce rates signal ISPs that the sender does not maintain their list, which drags down domain reputation and pushes subsequent sends into junk.
Validating your recipient list before sending removes dead addresses, catches disposable mailboxes, and flags spam traps. The bounce rate drops, reputation improves, and your carefully tested email actually reaches the inbox where it can render as intended.
Testing rendering without validating your list is like polishing a car that has no engine. Looks great. Goes nowhere.
Before your next send, check your list in uChecker. Upload your contacts and within minutes you will see which addresses are valid, which are risky, and which to drop.