EML Viewer

Open a saved email message, read what it contains, and save its attachments — without letting a mail client touch it.

Runs on your deviceEmailWorkingNo account needed

What this tool does

EML Viewer parses a raw RFC 822 message and rebuilds it the way a mail client would: headers are unfolded, RFC 2047 encoded-words in the subject and display names are decoded, the MIME tree is walked in full, quoted-printable and base64 transfer encodings are reversed, and every text part is decoded with the charset its own Content-Type declares — a part that declares none is read as UTF-8, falling back to Latin-1 if that fails. All of that happens in this browser tab, so the message file is not uploaded and never reaches a machine you do not control.

Opening a doubtful message in a real mail client is exactly what the message is counting on, so the body is treated as hostile input. The HTML is put through DOMPurify before anything is drawn: script, iframe, object, embed, form, input, link, base, svg and media tags are removed outright, javascript: links are dropped, the message's own stylesheet is scoped to the preview area so it cannot restyle the page around it, @import is stripped, and every surviving link opens in a new tab with rel=noopener. Images are blocked by default, which is why the tracking pixel that would report the message as read does not fire.

Attachments are listed above the body with their filename, media type and decoded size; the disposition and Content-ID are parsed but are not drawn on the page. With the extract option left on, each one is decoded into a file you can save — and so is every inline image the body carries, even though those count as part of the message rather than as attachments. Only the transfer encodings this parser can genuinely reverse are written out — 7bit, 8bit, binary, base64 and quoted-printable. A part in anything else, x-uuencode being the common survivor, is named in a short 'not extracted' line rather than saved as a file whose bytes are not the attachment.

The limits are worth knowing before you rely on it. This is a viewer: it cannot reply, forward, send or file anything, and it makes no judgement about whether the sender is genuine — the Received chain and the SPF, DKIM and DMARC results are Email Header Analyzer's work, not this tool's. Outlook .msg files are refused, because they are a binary format rather than RFC 822. S/MIME and PGP parts appear as opaque attachments and are not decrypted. And the rendering is a sanitised approximation, not a pixel copy of Gmail or Outlook.

How to use it

  1. Choose the message. One file at a time. The picker also accepts .mht, .mhtml and .txt, since a saved web archive or a message dumped to a text file has the same RFC 822 shape underneath.
  2. Decide what the images may do. Block all images is the default. Show embedded resolves cid: and data: images from the message's own parts. Show remote images too fetches them from the sender's server, which reveals that you opened it.
  3. Pick which body to read. Rendered HTML gives the sanitised layout; Plain text part shows the text/plain alternative as it was written. A message with no HTML falls back to text, and a message with no text part is converted from its HTML.
  4. Read the result, and save what you need. The header table sits above the sanitised body, with the attachment list and its total size between them whenever the message carries any; the MIME part count rides in the summary line. Leave Extract attachments ticked and each decoded part is offered as a separate file.

Processing & privacy

Runs on your device. Your file is processed directly in this browser.

Common use cases

Inspecting a phishing report a colleague forwarded

The suspect message arrives as an .eml attachment nobody wants to double-click in Outlook. Read the sender, the subject and the body here with images and scripts already disarmed.

Working out what an automated mail actually said

A billing notice or a CI alert that rendered as an empty box in the client gives up its real body and its part count — and once you allow embedded images, a line counting the inline references that never found a matching Content-ID.

Recovering an attachment from an archived message

An .eml pulled out of a backup, a ticketing system or a legal export gives up its files without importing the whole message into a live mailbox first.

Debugging mail your own application sends

Save the SMTP output as a file and see what a recipient would: the decoded body, how many parts your library produced, and whether every attachment comes back out with the filename and size you intended. For the tree and the per-part encodings behind that, open the same file in MIME Viewer.

Questions

Is my message uploaded anywhere?
No. The file is read into memory in this tab, parsed there and rendered there, and no request ever carries the message off the machine. One thing does come down the wire: the sanitiser, a script fetched from this site the first time you run the tool. After that the only setting that reaches the network at all is Show remote images too.
Can it open Outlook .msg files?
No. A .msg is a binary Compound File, not an RFC 822 message, so it is detected and refused instead of being shown as rubbish. Drag the message out of Outlook, or use Save as with the .eml format, and open that file here.
Does blocking images really stop the sender learning anything?
For that message, yes: no remote request is made, so a tracking pixel never loads and no open can be inferred. Choosing Show remote images too reverses it, and the option says as much — the requests go to the sender's server from your address.
Why do images inside a .mht archive stay blocked?
MHTML archives point at their parts with Content-Location, while inline images here are resolved by Content-ID. The parts are still parsed and still come out as saved files, but the references to them are read as remote ones: blocked under either of the first two image settings, and fetched from the original site rather than from the archive if you choose Show remote images too.
Does it tell me whether a message is genuine?
No. It shows what a message contains, not who really sent it. Delivery hops and authentication results are Email Header Analyzer's job, and the structure of the parts on their own is MIME Viewer's.
What happens to a forwarded or nested message?
A message/rfc822 part is parsed as a message in its own right and counted in the MIME part total, down to a nesting depth of 24, so anything it carries turns up in the outer attachment list and can be saved. The forwarded message itself cannot: nested messages are skipped when that list is built, so the .eml wrapping them is never offered as a file, and only the outer message's own body is rendered.
Why does the date differ between the panel and the copied text?
The header table prints the Date header in your browser's own time zone, while the plain-text version of the same message normalises it to UTC. Neither one is the raw header: that is printed exactly as written only when the date cannot be parsed at all.

Related tools