Email HTML previewer
Runs in your browser
Sometimes you have the markup and not the message: a template you are about to send, or the source of something that arrived looking wrong. Paste it here and see it drawn, without opening it in a mail client and without being counted as having read it.
It is drawn in a frame that has no permission to do anything. No scripts run, no images are fetched, no link goes anywhere and no form submits. Nothing you paste is uploaded, so there is nothing on our side to store or hand over. Disconnect from the network entirely and it still works — that is the check worth doing.
To be exact about it: the page itself is not silent. Like every page here it loads our analytics, which counts the visit and never sees the message. What never leaves your browser is what you paste.
Render a message
The message will be rendered here, in a frame that cannot run it.
What is actually happening to the markup
Why rendering a message is dangerous
HTML is not a document format, it is a program. A message can carry a <script> block, an onerror attribute that runs code the moment an image fails, a link whose address is javascript: rather than a URL, or a stylesheet fetched from a server that then knows you looked. Dropping that markup into a page is how a previewer becomes the attack.
There are two honest ways out. Strip everything dangerous out of the markup before rendering it, or render all of it somewhere that has no permissions. Stripping is the popular answer and it is the fragile one: a sanitiser is a list of everything anyone has thought of, and the interesting inputs are the ones nobody has.
What this page does instead
The message goes into a frame declared with an empty sandboxattribute, which is the browser’s strongest setting rather than a default. The frame gets its own throwaway origin, so it cannot read this page. It has no permission to run JavaScript, submit a form, open a window, or navigate the tab it sits in. None of that is our code enforcing it — the browser refuses, and it refuses the same way for markup nobody has seen before.
The frame also carries its own content policy naming no server at all, so an image, a font or a stylesheet with an address in it is never fetched. That part matters more than it sounds: a remote image in a marketing email is the open tracker, and a previewer that loaded it would report your read to the sender on your behalf.
Your markup is not edited on the way in. Nothing is stripped, nothing is rewritten — what you see is what you pasted, with the permissions taken away rather than the content. The list under the preview is the browser’s refusals, itemised.
Why the images are missing
They are missing on purpose, and mostly they would be missing anyway. Every major mail client blocks remote images until the reader asks for them, because loading one is what tells the sender the message was opened, when, and from roughly where.
Images that live inside the message rather than on a server — the ones addressed cid: — cannot be shown here either, but for a duller reason: they are attachments, and pasted HTML on its own does not carry them.
What this cannot tell you
It cannot tell you how the message will look to a recipient. This is your browser, and no major mail client renders what your browser renders: Gmail strips the <head> and much of the CSS in it, Outlook on Windows renders through Word, and Apple Mail applies its own dark-mode transform. Every one of them will draw this differently from the frame above.
So read it as what the sender wrote, not as what a reader gets. For the second question you need the real clients, and no free tool can honestly claim to substitute for them.
It also cannot tell you a message is safe. A message with nothing switched off is still a message from whoever sent it, and the link that looks ordinary is the one worth checking.
If you are debugging your own template
The findings list is useful here in a way it is not for reading someone else’s mail. Scripts and forms in your own template are dead weight — no client will run them, so they are bytes that only make your message look more like spam to a filter. External stylesheets are the same story: most clients drop them, which is why bulk mail is still written with inline styles and tables.
If the preview looks plainer than your design, that is usually the answer, and the fix is to inline the styles rather than to link them.
The address underneath all of it
Blocking images and refusing scripts is good hygiene, and it does not change the thing that made the message reachable: the sender has an address that gets to you, and it is the same address they can sell, match against a breach, or hand to a broker.
Giving each sender a different one does change it, which is the thing Maski does. When one of them starts behaving badly, you turn off that address instead of arguing with them.
One of the free email tools.