Email (.eml) Viewer

about this tool

Drop in the .eml your mail client saved and read what is actually in it: the headers, both versions of the body, every attachment, and the whole MIME tree underneath.

Remote images are never fetched

An <img> in an email that points at the sender's server is a tracking pixel far more often than it is a picture. Loading it tells them the address is live, when you opened the message, roughly where you were and what you read it on. That is the entire reason the tag is there.

So this does not load them. They are counted, the first is shown, and nothing leaves your browser — which is the only way a viewer can honestly claim the file stays with you. There is no "load images anyway" button, because the moment there is one, the promise has a footnote.

Images carried inside the file, referenced as cid:, are shown. Those are already in your hands and cost nothing to display.

Safer than opening it in a mail client

Nothing is fetched, no script can run, and no link is followed until you choose to. The HTML body goes through the same sanitiser the Markdown editor uses, and the panel counts what it removed.

Read that count as housekeeping, not as a threat level. Mail HTML is built out of width, bgcolor, cellpadding and <font>, none of which the allowlist carries, so a perfectly ordinary marketing email loses a dozen attributes on the way in. It tells you the message was written in 2003, not that it is dangerous.

What this cannot do is vouch for an attachment. It will hand you the file with its real name and type; what happens after that is between you and your antivirus.

Two bodies, and why they differ

Most mail is sent as multipart/alternative: a plain-text version and an HTML version of the same message, with your client picking one and hiding the other. Both are here.

They are supposed to say the same thing. A message where the text version is bland and the HTML version carries the urgent demand is worth a second look — that split is deliberate, and it exists because filters read the part humans do not see.

The tree, in full

A mail file is a tree, and a mail client shows you one leaf of it. Every part is listed here with its type, its transfer encoding and its decoded size, including the ones nothing renders. A part your client hid is visible.

A forwarded message arrives as a message/rfc822 part — a whole email inside the envelope of another — and is opened as one, nested where it sits.

Attachment names get the same treatment. A filename that is not plain ASCII is encoded across several header parameters under RFC 2231, sometimes split across filename*0*, filename*1* and more. Readers that handle only the plain filename= form show the raw encoding, or nothing. Both forms are decoded here, as are the =?UTF-8?B?…?= encoded-words in the subject and the sender's name.

What it does not read

Outlook's .msg is a different format entirely — a compound binary document, not RFC 5322. It is recognised by its header bytes and refused, rather than parsed into a page of garbage that looks like an answer.

Encrypted S/MIME and PGP parts are listed in the tree and can be saved, but there is no view that renders them: they are ciphertext, and decrypting them needs a key this tool has no business holding. Armoured PGP written inside an ordinary text body does show, because at that point it is just text.

To check whether the message really came from who it claims, the email header analyser reads the delivery chain and what SPF, DKIM and DMARC said about it. For a link you found in the body, the URL parser takes it apart, and zip & unzip will look inside an archive you were sent without unpacking it.

questions

Are the images in the message loaded?

Remote ones, never. An <img> pointing at somebody else’s server is a tracking pixel far more often than it is a picture: fetching it confirms the address is live, records when you opened the message and roughly where you were. This tool promises the file does not leave your browser, so it cannot then reach out to the sender. Blocked images are counted and the first is shown. Images carried inside the file, referenced as cid:, are displayed — those cost nothing.

Is it safe to open a suspicious email here?

Safer than in a mail client, which is much of the point. Nothing is fetched, no script can run — the HTML goes through the same sanitiser the Markdown editor uses, and the page says how many things it removed — and no link is followed until you click it. What it cannot do is tell you the attachment is safe: it will hand you the file, and what happens next is your antivirus’s business.

How is this different from the email header analyser?

That one takes headers you pasted and reads the delivery chain, SPF, DKIM and DMARC. This one opens the whole file: the bodies, the attachments and the MIME tree. Use the header analyser to answer "is this really from who it says", and this to answer "what is actually in it".

Why are there two bodies?

Most mail is sent as multipart/alternative: a plain-text version and an HTML version of the same message, and your client picks one. Switch between them here — they are supposed to say the same thing, and a message where they do not is worth a second look.

Where do I get a .eml file?

In Apple Mail and Outlook, drag the message to the desktop. In Thunderbird, right-click and Save As. Gmail has no .eml export, but "Show original" gives you the same text, which you can paste in. Outlook’s .msg is a different, proprietary format and is not read here.

What if the file has an attached email inside it?

A forwarded message arrives as a message/rfc822 part, which is a whole email in its own right. It is opened as one and appears in the tree with its own headers and parts, nested under the message that carried it.

Why does an attachment name have percent signs in it?

It should not, here. A filename that is not plain ASCII is encoded across several header parameters under RFC 2231, and a viewer that reads only the simple filename= form shows the raw encoding or nothing at all. Both forms are decoded, including names split across filename*0*, filename*1* and so on.