Search for eml to pdf and the first page is FreeConvert, Zamzar, CoolUtils, PDFCandy, GroupDocs and Aspose. Every one of them works the same way: you choose the file, the file goes to them, a converted file comes back. Zamzar will email you the result, which means the message you were converting now exists in a second mailbox as well.
Search for mbox viewer and it is not web software at all. It is Windows and Mac downloads — 4n6, MacUncle, RecoveryTools — so the choice on offer is between sending a stranger your mail and installing something to read it.
The odd part is that the warning is already on the page. The most-linked guide to opening .eml files tells its reader not to put anything privileged through a random online tool, and then lists online tools, because there was nothing else to list. This article is that gap, and it is the only one in this section that argues rather than explains.
What you are actually handing over
An .eml is not a copy of what the mail client showed you. It is the message as it travelled, and the visible part is the smaller half.
Above the body sits the header block. It contains a Received line for every server that handled the message, each with a hostname and usually an IP address, which between them describe the route from the sender's network to yours. It contains the full To and Cc — everyone on the thread, not just the names your client chose to show. It contains the Message-ID, the In-Reply-To and References that place the message in a thread, the DKIM signature, and whatever X- headers the sending organisation's own systems attached on the way out: a scanner verdict, a queue identifier, sometimes a department.
Below it, the body is usually there twice — a plain text version and an HTML one — and the attachments are inside the same file, Base64 encoded, which is why a 4MB photo makes a 5.4MB email. And below that, in most business correspondence, is every earlier message in the thread, quoted.
So the unit you are uploading is not "an email". It is a conversation, its participants, its routing and its files, in one object.
The use case is the problem
CoolUtils markets its converter as producing a court-ready PDF. That is an accurate description of what people want and an alarming description of what is being sent.
Nobody converts an email to PDF for fun. They do it because the message has to go into a filing, a grievance, an insurance claim, a dispute with a landlord, a disclosure bundle. The reason the file needs a header block on the page is the same reason it should not leave the building: it is evidence, and it is usually somebody else's correspondence as well as yours.
What a deletion promise covers, and what it does not
This is where it is worth being precise, because the vague version of this argument is wrong and does the honest version no favours. The risk is not that these companies are crooked or that hackers are waiting. Most operate competently and most keep their word.
The specific things a retention promise does not reach are these.
TLS ends at their edge. The connection protects the file from anyone watching the network, and that part genuinely works. It terminates at a load balancer or a CDN node, and from that point onwards the message is plaintext on their infrastructure — because something has to read it in order to convert it. There is no design that avoids this.
Logs keep more than contents. Message bodies are rarely written to a log. Filenames very often are, and a request log line naming grievance-final-2026.eml outlives the file it refers to and sits under a different retention schedule than the file did.
A policy is a claim about behaviour. Nothing you can observe from your side distinguishes a service that deletes after an hour from one that intended to and has a cleanup job that has been failing since March. That is not an accusation; it is the shape of the thing. You are being asked to trust rather than to check, which is fine for most files and is a decision worth making deliberately for this one.
What exists can be compelled. A preservation order or a lawful request reaches whatever a company is holding at that moment. This has nothing to do with its intentions and everything to do with whether a copy exists.
The thread running through all four is that each is proportional to the existence of a copy. There is a longer version of this covering the whole route a file takes; the summary is that reducing copies reduces every one of these at once, without having to trust anyone more or less.
The work never needed a server
The part that makes the upload avoidable rather than merely regrettable is that reading an email is not hard.
An .eml file is text in the layout RFC 5322 describes: header lines, a blank line, then the body. If the message has attachments or two body versions, MIME splits it into parts separated by a boundary string the headers declare. Decoding an attachment is Base64. Decoding a subject line with accented characters in it is a defined encoding. An .mbox is those same messages written one after another, so a single parser reads both — which is why splitting an archive into messages is taking it apart rather than converting anything.
All of that is string handling. It needs no library a browser cannot load and no computation a phone would notice. The one operation here with a real cost is rendering a message as a PDF, and rendering a document is the thing a browser is already for.
What running it locally does and does not promise
The honest claim is narrow, and it is worth stating as a limit rather than a feature.
It can say the file does not leave. Not as a policy but as an absence: there is no endpoint to send it to, so there is nothing to delete afterwards, nothing to include in a breach and nothing to hand over on request. You can verify this yourself in fifteen seconds — load the page, disconnect from the network, then use it. Work that happens on your machine keeps happening.
It can say the sender is not told. A message that quietly fetches a remote image reports back the moment it is displayed. A viewer that does not fetch them does not fire that request, so opening the file tells the sender nothing. Every upload converter renders those images, on their network rather than yours.
It cannot re-verify authentication. Checking SPF or DKIM properly means asking DNS for what the sender's domain publishes, and a browser has no way to make that query. So the header analyser reads the Authentication-Results line the receiving server wrote at the time and explains it. That is the same information your mail provider used, and it is not the same as an independent check.
It cannot open a .pst. Outlook's whole-mailbox database is a different kind of file entirely, and the distinction is worth knowing before you go looking for a tool.
It does nothing about your own device. The file is on your disk either way. A browser-only tool changes who else has a copy, and that is all it changes.
What to do instead
If the message is routine — a receipt, a newsletter, something you would forward without thinking — upload it wherever you like. Nothing here says otherwise.
If it is correspondence you would not forward, the test is simple and does not require trusting a claim on a landing page. Open the network tab in your browser's developer tools before you use a tool. A server-based one sends a request the size of your file. A local one sends nothing at all after the page has loaded, because there is nothing for it to send.