Show the Working

EML to TXT

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, readable, with the headers that tell you who sent it.

Five headers are kept — From, To, Cc, Date and Subject — and the body is the plain-text part the sender wrote. If they sent only an HTML version, that is reduced to text and the file says so, because a flattened layout is not the same thing as a plain-text version somebody wrote. Attachments are listed by name, type and size rather than disappearing without trace.

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 keep the layout, because plain text has none. A message built as a table of coloured boxes comes out as the words in reading order, which is usually an improvement and is occasionally a scramble. If the layout matters, take the HTML instead.

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