How to Test an HTML Email Before Sending

1. Prepare the Final Sending Source

Test the version closest to what recipients will receive. Template variables, CSS inlining, link tracking, and platform imports can change a document after a design review. Export the assembled HTML from the sending workflow when possible, not an earlier mockup.

Keep a copy of the pre-import source. Comparing the two reveals whether a platform removed a style block, rewrote a destination, added parameters, or changed an image reference. Use realistic content: short placeholder copy can hide wrapping and localization failures.

2. Validate HTML and CSS

Check the doctype, html, head, body, document language, malformed markup, duplicate IDs, empty destinations, and missing image sources. Email clients may repair markup, but relying on undocumented repair behavior makes results harder to predict.

Separate syntax errors from compatibility considerations. A malformed declaration is an error; a valid CSS feature with uneven support needs evidence and a fallback. Google publishes a Gmail CSS reference and says unsupported properties or selectors may be ignored. That supports client-specific wording, not a claim that a feature fails everywhere.

Run the free HTML email test for deterministic findings. Correct the source in the HTML email editor and repeat the test until every remaining warning is understood rather than merely hidden.

3. Check Images and Links

Every meaningful image needs a reachable source and text that replaces its purpose. MDN explains that the alt attribute supplies a replacement when an image is unavailable and recommends intrinsic width and height to reserve space. Decorative images should use empty alt text rather than omitting the attribute.

Inspect links for empty href values, relative destinations, placeholder domains, insecure HTTP, generic labels, duplicated URLs, and campaign parameters. A remote request can identify a redirect, 404, or server error, but a blocked request should remain unable to verify. Open high-value destinations manually after the sending service finishes rewriting them.

4. Test Responsive Layout

Render at 320, 375, 390, and 430 pixels for wide tables, fixed containers, image overflow, button wrapping, and long strings. Use 768 and 820 pixels to find breakpoint gaps. At 1024 and 1440 pixels, confirm that the email stays intentionally constrained instead of stretching every line.

Media queries can adapt layout to width and orientation; MDN describes them as a core responsive-design mechanism. Email processing varies, so make the base layout usable even if a query is removed. A browser preview measures browser layout—it does not reproduce Gmail or Outlook.

5. Review Accessibility Beyond Automation

Automated checks should cover language, image alternatives, link and button names, heading order, duplicate IDs, ARIA values, computable contrast, and table semantics. W3C guidance emphasizes meaningful structure, alternatives, reflow, keyboard access, and sufficient contrast.

Then perform a human review. Read the message without images. Check that links make sense out of context, source order matches reading order, and color is not the only information carrier. Zoom, reflow, and use relevant assistive technology. No automated report establishes complete WCAG conformance.

6. Inspect Tracking, Size, and Security

List UTM source, medium, campaign, content, and term values. Confirm that one campaign does not accidentally use several names. Identify one-pixel images without automatically declaring their intent. Measure raw bytes and DOM complexity so unexpectedly large output is visible.

Reject scripts, JavaScript URLs, iframes, objects, embeds, forms, event handlers, and automatic navigation. An email should not need active browser scripting to communicate its essential message. Remove unused comments and styles only after checking what the sending workflow requires.

7. Send Controlled Client Tests

Source checks and browser previews cannot replace a sent-message test. Send through the same platform, account configuration, and transformation pipeline intended for production. Test the client and device environments important to the audience, including relevant appearance settings.

Confirm subject, preheader, sender identity, plain-text alternative, images-off experience, links, unsubscribe path, personalization, localization, and tracking after delivery. Record the final source version and approval rather than depending on memory.