Email HTML Previewer

Paste HTML email code and preview it in simulated email client frames (Gmail, Outlook, Apple Mail). Responsive test.

How to Use Email HTML Previewer

1

Paste your HTML

Enter the HTML email code you want to preview.
2

Preview the rendering

See how the email looks in the embedded preview pane.
3

Test at different widths

Switch between desktop and mobile viewport sizes to check layout.

Tested tool guide Tested browser tools Checked August 16, 2026

What Email HTML Previewer does, with a checked example

Paste an email's HTML source into the field and the tool renders it in separate frames labeled Gmail, Outlook, and Apple Mail, each approximating how that client treats your markup and CSS, plus a narrower view for checking the phone layout. The thing most people get wrong: there is no single correct render. Those three clients support different subsets of CSS, so the same code legitimately looks different from frame to frame, and the differences are the signal to act on, not a bug in the preview. The paste is processed in the page; nothing is sent anywhere.

Worked example

A concrete input and expected output from the current implementation.

Input

<table role="presentation" width="100%"><tr><td style="padding:24px;background:#f4f4f4;font-family:Arial,sans-serif;text-align:center;"><h1 style="color:#1a73e8;">Product update</h1><p>Version 2.4 ships today.</p><a href="https://example.com" style="display:inline-block;padding:12px 24px;background:#1a73e8;color:#ffffff;border-radius:6px;text-decoration:none;">Read more</a></td></tr></table>

Expected output

All three frames show the same single-column card: a light gray block centered in the email, a blue "Product update" heading, one line of body text, and a blue rounded "Read more" button. At the phone width the layout is unchanged - a single column needs no reflow - and nothing scrolls sideways.

Every style in this snippet is inline and the structure is one centered table cell, so no client-specific CSS support or media query is involved. All three simulated clients render it the same way, and the narrow view needs no breakpoint because the column never had siblings to stack.

How the result is produced

Simulated client frames

The code you paste is rendered once per client into separate frames: Gmail, Outlook, and Apple Mail. Each frame approximates that client's rendering environment, including the CSS it honors and the width it typically shows email at, so one source produces several side-by-side renders. Comparing them shows where your layout depends on CSS a particular client does not apply.

Responsive test

Email layouts are built for a wide desktop column and a narrow phone stack. The responsive view renders the same code at phone-like widths, so media queries and fluid tables react to the narrower viewport the way they would on a phone. Watch whether columns stack and whether text stays readable at that width.

Good uses

Pre-send check of a campaign: paste the final code and scan the three frames for breakage that only one client causes, such as a layout technique Outlook mishandles while the other frames render it fine.
Responsive development loop: keep the narrow view open while you adjust breakpoints and stacked-column CSS until the phone layout is readable and nothing overflows.
Vetting code you did not write: a downloaded template or an agency file goes through the frames before you add your own content, so surprises surface before the send, not after.

Limits and checks

Frames approximate, they do not certify: a clean preview does not guarantee the same result in a live app, on a specific phone, or in a recipient's dark mode, custom font, or zoomed view. For list-wide campaigns, follow up with a real-client test.
Clients change over time and between platforms: Gmail web, Gmail mobile, and the Outlook app render differently from each other and from older versions, so treat the frames as a snapshot of typical behavior, not a permanent verdict.
The narrow view is a width test, not a device test: it shows the email at a phone-like width inside the simulated client, not touch targets, safe-area insets, or the real chrome around the message. A layout that fits the frame can still feel cramped in an actual phone app.

Common questions

Can I preview an email that uses merge tags or external images?

The tool renders the code as pasted. Merge tags like {{first_name}} are plain text to the preview, so they appear literally, and external images load only if the browser can reach their URLs. A broken image in a frame is usually an unreachable asset URL - worth fixing regardless, since many clients block image auto-loading anyway.

If the three frames agree, is the email safe to send?

Not automatically. Agreement across frames is a strong signal, but real recipients use specific apps, platforms, and settings - dark mode, font size, zoom - that no preview fully covers. Use the preview as the fast first pass, then send yourself a test email to a few real inboxes before anything goes to the whole list.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.