Show the Working

EML to HTML

Your email never leaves your browser, and nothing is downloaded to make this work. That matters more here than on most pages: an email is the most personal file most people own, and the usual way to convert one is to upload it to a stranger who then has it.

…or drop one anywhere on this page.

The message as it was meant to look, with everything that phones home taken out.

This is the one worth explaining. HTML email is full of remote references, and the commonest is an image one pixel across at an address unique to you: open it and the sender is told you read the message, when, and roughly where from. Every remote image, stylesheet, frame and script is removed, the number is shown on screen, and a note is left where each picture was so the message does not silently lose a piece. The file also carries a policy line forbidding any fetch at all, in case something was missed.

Why an email is not a safe thing to open twice

Most marketing email carries a tracking pixel: an image one pixel square, invisible, loaded from an address unique to you. Your mail client may have blocked it; a converted file opened in a browser will not. Opening it tells the sender that the message was read, at what time, and roughly from where — a second time, months later, from a file you thought was a local copy.

So everything that fetches is taken out: remote images, stylesheets, frames, scripts, and background images hidden in style attributes. The count is shown on screen rather than claimed, because “we cleaned it” with no figure attached is not something anybody can check. What is left carries a Content-Security-Policy line forbidding any outside fetch, as a second line of defence in case one slipped through.

What is actually in an .eml, and why it needs no library

Headers, a blank line, then the body. That is RFC 5322, and it is text. What makes it harder than it looks is everything added since: a long header is folded across several lines, so reading line by line cuts a Subject in half; anything not ASCII arrives as =?UTF-8?B?…?=, so skipping that step turns every accented name into nonsense; the body may be a tree of parts, with a plain and an HTML version of the same message and the attachments beside them; and the parts are encoded as base64 or quoted-printable, the latter with a line-continuation rule that leaves an = through the middle of words if you miss it.

The character sets are free, and that is the whole reason this is a page rather than a program. Your browser already decodes windows-1252, ISO 8859, Shift_JIS, GB18030 and the rest — so a message written in any of them is readable here without fetching anything.

Why there is no EML to PDF here

The same reason there is none on the book pages: it is not a conversion, it is typesetting. A PDF has pages and an email does not, so something has to choose the page size, the typeface, the margins and where every break falls. Those are real decisions, and a converter making them silently has made them for you. Print the HTML from your browser and you get a PDF with those choices in front of you, which is the right place for them.

What it will not do

It will not show you the pictures that were fetched from elsewhere, and that is the point rather than a shortcoming. Pictures sent inside the message are marked where they sat but not embedded, because an email's inline images are attachments underneath and the attachments converter is the honest way to get them.

It does not open Outlook .msg files, which are not email text at all but a Microsoft compound document, nor .pst or .ost archives. It cannot read an encrypted message — S/MIME or PGP — without the key, and says so rather than producing nonsense. And it does not verify a signature: a message is reported as signed, which is not the same as reported as genuine.

Where to go next