🖼 HTML Paste Preview

Paste HTML and render it instantly in a sandboxed iframe on the right. Perfect for HTML email mockups, Outlook compatibility, and device-width testing.

100% Free No signup Browser-only 5 languages Dark mode

🔒 Privacy and Security

・Rendering happens in a local sandboxed iframe (sandbox=allow-same-origin)
・Script tags are NOT executed (disabled by sandbox)
・Your HTML text is never sent to any server
・No external libraries — pure JavaScript

📝 HTML Input

📁 Files

0 chars

👁 Preview

BG:

📖 Where people get stuck

Renders pasted HTML into a sandboxed iframe as you type, with switchable widths and backgrounds. <script> does not execute and the HTML is never uploaded. What you see here is only how a modern browser would draw it — if the target is HTML email, start from the assumption that this preview and the inbox are two different things, because every mail client has its own rendering path and rewrites the HTML before displaying it.

Case	What happens	What to do
It looks fine here and falls apart only in Outlook	Outlook on the Windows desktop renders HTML with the Word engine, not a browser one. The upshot is that `float`, `position`, `max-width`, `background-image`, rounded corners and box shadows are ignored wholesale. A modern layout built from `<div>` elements will almost certainly collapse into a single column, and no preview here can reproduce that. A substantial share of the world still opens mail through this path.	Build email HTML from nested `<table>` elements and set widths with the `width` attribute rather than CSS. It looks like markup from 2005, and it is still the only reliable approach. 600px is the de facto standard overall width. If you genuinely need a background image, add VML inside an `<!--[if mso]>` conditional. Always confirm on real clients — mailing it to yourself and opening it in Outlook, Gmail and iOS Mail catches nearly every fatal break.
The classes do nothing, or the style tag disappears entirely	Many mail clients strip the entire `<head>`, and with it your `<style>`, from what they received. They embed only the body into a page of their own, so nothing in the head survives. Gmail keeps some of it, but the behaviour varies by client and version, so working on the web and not working in the mobile app is an entirely ordinary outcome. This preview interprets `<style>` normally, so the difference is invisible here.	Inline every style into a `style=` attribute. Doing that by hand is impractical, so put an inliner such as Premailer or juice into the build — it expands the CSS you wrote in `<style>` onto the individual elements. Media queries and pseudo-classes cannot be inlined, though, so handle responsiveness not by branching on width but by building something that cannot break at any width in the first place: one column, images at `width:100%`, body text at 14px or larger.
The images do not show up	If nothing appears in the preview, a relative path is almost always the cause: `./img/logo.png` has no base page to resolve against inside the iframe. In real mail, though, even an absolute URL normally shows nothing at first — Gmail and Outlook block external images by default and load them only when the recipient clicks to show them. In other words, what many recipients see first is your email with the images missing.	In the preview, use an absolute URL or a data URI. In production, whether the message still works with images blocked is effectively a design requirement: always write `alt` text, and put a similarly coloured `bgcolor` behind logos and buttons so the text remains readable without them. Making the whole message a single image is the worst possible choice — blocked, the content vanishes entirely, and it raises your spam score. Embedding as a data URI is not a workaround either, since Gmail does not support it.

The width presets only change the viewport width; they do not emulate a device. Dark mode in iOS Mail and Gmail automatically inverts the colours of the HTML it receives — that is why an email designed as dark text on white arrives as pale text on a dark background, with a white rectangle left around the logo (a transparent PNG avoids it). On security: sandbox stops scripts, but it does not make pasted HTML safe. CSS alone is enough to build a convincing fake login screen, and <a href> still works. When previewing HTML of unknown origin, do not click the links inside it — if the point is to check the appearance, you have no reason to visit the destinations.

📖 How to Use

1

Paste HTML

Paste HTML into the textarea on the left, or load an .html file.
2

Select device width

Choose Desktop, Tablet, Email 600, or Mobile 375 to check responsive layout.
3

Switch background

Toggle white, dark, or checker. White is standard for HTML emails.

❓ Frequently Asked Questions

Do script tags run?

No. The iframe sandbox (allow-same-origin only) blocks scripts so untrusted HTML can be previewed safely.

Can I preview HTML email?

Yes. Use the Email 600 preset with white background for an email-client-like layout. Always test in real clients (Outlook, Gmail) for final QA.

Is the HTML sent to your server?

No. Rendering happens in a local iframe in your browser. There is no server endpoint.

🔗 Related Tools

🐛 Found a bug or issue with this tool?

Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.