Check the main container width, column layout, long subject lines, and backgrounds in wide-screen clients.
Rendering lab · Four ways to review
Don’t review HTML email in just one inbox
Review the same email on wide screens, narrow screens, with images off, and in plain text. Make the information usable first, then fine-tune pixel consistency.
Check whether columns stack, buttons are tappable, and the message needs horizontal scrolling.
Confirm that alt text, background colors, and reading order still communicate the core action.
Verify that facts, complete links, support options, and unsubscribe information remain available in the fallback version.
QA worksheet
For each view, record “pass,” “acceptable difference,” or “release blocker,” and include the specific client and screenshot.
| View | Primary concern | Release-blocking signal |
|---|---|---|
| Desktop | Container, columns, background, and long text | Content clipped, buttons overlapping |
| Mobile | Stacking, touch targets, and horizontal overflow | Must zoom to use |
| Images off | Alt text and information order | Key code or action disappears completely |
| Plain text | Facts, URLs, and unsubscribe details | No single actionable path |
Container and table layout
Many email clients still rely on table layouts. Give the main container a sensible maximum width and let it fit within narrow viewports instead of relying on page zoom.
Check whether nested tables, fixed-width images, or long URLs stretch the page. A one-pixel difference is usually fine; horizontal scrolling usually isn’t.
Fonts and text fallback
When custom fonts fail to load, fallback fonts should preserve a readable size and similar character widths. Don’t rely on ultra-light weights for body text or lock line height too tightly.
Test mixed-language text, numeric codes, and long localized copy. Buttons must remain inside their containers when French or Portuguese labels expand.
Images and alt text
When remote images are blocked, the logo may disappear, but the product name, verification code, amount, and primary action must remain. Use concise alt text for informative images and empty alt text for decorative ones.
Declare image dimensions to reduce layout shift while loading. Don’t repeat nearby visible copy in alt text.
Buttons and links
Make button hit areas large enough, state their purpose clearly, and keep color contrast readable in both default and dark modes. If rounded corners and shadows fail, the link itself must still work.
Also provide complete, copyable URLs, especially in recovery and confirmation emails. Check that a failed tracking redirect still leaves a way to recover.
Dark mode
Some clients automatically invert backgrounds and text while leaving branded images unchanged. Check whether transparent logos, outlined icons, and colored code blocks remain readable.
Don’t sacrifice accessibility to fully prevent inversion. The goal is to preserve hierarchy and contrast, not to force identical colors in every client.
Responsive stacking
Two-column content should stack in semantic order on mobile. If an image sits on the right on desktop, the mobile version should still present the heading and key action first.
Check the base layout when media queries are ignored. Core email content must remain readable in clients that don’t support advanced CSS.
Accessible reading
Heading levels should support navigation, and link text shouldn’t all say “click here.” Use text or graphics, not color alone, to convey success, warnings, and errors.
The reading order must match the visual order. Use appropriate attributes for layout tables so screen readers don’t announce every decorative cell as a data table.
Plain-text consistency
Plain text isn’t what remains after stripping HTML tags. It needs clear paragraphs, action names, complete URLs, a support address, and legal information.
Amounts, times, and verification-code expiry periods must match between HTML and plain text. Whenever one template changes, recheck the other.
Dynamic-field stress testing
Test empty names, very long names, multibyte characters, unusually large amounts, and dates across time zones. If template variables fail, never send braces or internal field names to users.
Preview and production data should share the same structure, but never copy real customer information into a public test inbox.
Remote resources and tracking
Confirm that images use secure URLs and that resource hosts allow access from email clients. If tracking pixels are blocked, the message and key actions must remain unaffected.
Don’t treat “open rate” as an absolute measure of email reading. Privacy proxies and blocked images can significantly distort it.
How to grade differences
Differences that affect comprehension, actions, or legal information should block release. Minor changes to corners, shadows, or fonts are usually acceptable, but record them.
Grade by user impact first, then by pixels. After fixing one client, regress all other views to prevent conditional styles from causing new issues.
Complete the loop
Send the email through the real delivery path to an isolated address, record the arrival time, open the message, and activate the button. A screenshot proves appearance, not the target URL or verification-code status.
Remove demo data after receiving the real sample to avoid mistaking example content for product output.
Send the real template to ForwardTop test inbox, while recording the subject, sender, arrival time, and HTML body to complete an end-to-end check.