MIME Viewer

Paste a raw message and map its MIME parts, encodings and attachment structure.

Runs on your deviceEmailWorkingNo account needed

What this tool does

MIME Viewer takes the source of a message and turns it into an inventory. It finds the boundary string declared in the Content-Type header, cuts the body along it, and starts again on each piece, so a multipart/mixed carrying a multipart/alternative comes back as a numbered set of rows — 1, 1.1, 1.1.2 — instead of a wall of base64. Every row gives one part's content type, charset, transfer encoding, disposition, filename or Content-ID, a raw size — the body alone for a leaf, the whole branch for a container — and, for leaf parts only, the size that body decodes to.

It also counts what is structurally wrong. A transfer encoding it cannot reverse, a text part carrying no charset (which silently makes it US-ASCII), base64 containing characters outside the alphabet, a multipart whose closing boundary never arrives because the message was cut short, a boundary declared but absent from the body, and a multipart message with no MIME-Version header are each written out as a warning beneath the table, with the tally joining the part and attachment counts in the summary line.

Every stage — the split on boundaries, the base64 and quoted-printable arithmetic, the byte counting — is JavaScript running on your own device, and the source you paste goes no further than the page. That is worth having for message source, because it reproduces the message whole: each address it was sent to, everything written in the body, and the name of anything attached. One consequence of working from pasted text rather than the original file is that sizes are measured from what your clipboard produced. If line endings were rewritten on the way across, or a body arrived 8-bit in a charset other than UTF-8, the byte figures move a little: a CRLF message pasted as LF loses a byte per line from every raw size, and from the decoded size of a quoted-printable part too, because its hard line breaks are decoded as they stand. The decoded size of a base64 part is the one figure that holds, since it is worked out from the alphabet characters alone and no amount of rewrapping changes them.

This is a map, not an unpacker. It does not write attachments out as files, it does not render the HTML part, and it neither verifies a signature nor decrypts anything — a multipart/signed or S/MIME message shows its parts while the payload stays opaque. Two settings, List each part's headers and Text preview per part, build a longer text report with per-part headers and decoded previews, but nothing on the page displays that report: the output pane is given to the parts table and Copy output copies the table, so as the tool stands today both controls change nothing you can see or take away. When you need the attachments themselves or the message as a human reads it, EML Viewer opens the .eml file directly.

How to use it

  1. Get the raw source. Most clients will hand it over: Gmail calls it Show original, Thunderbird View Source, Apple Mail Raw Source. An .eml file opened in a text editor is the same thing.
  2. Paste the whole message. Headers first, then a blank line, then the body. The Load sample button fills the box with a small multipart message if you want to see the layout first.
  3. Read the parts table. Each row is one part, and the dotted number says where it sits: 1.1.2 is the second child of the first child of the message.
  4. Check the count underneath. The summary reports parts, attachments and problems. A non-zero problem count means something in the structure does not hold together.
  5. Copy it out if you need it elsewhere. Copy output writes the table as CSV, one row per part, with any warnings appended after it, so it can go straight into a ticket or a reply to whoever sent the message.

Processing & privacy

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

Common use cases

An attachment the recipient never saw

The table shows whether the part was in the message at all, what it was named, and how it was declared — attachment, inline, or nothing at all.

Text arriving as question marks or mojibake

A dash in the charset column of a text part means none was declared, so US-ASCII is assumed and accented characters turn into rubbish; that part is also counted as a problem.

A newsletter that renders as plain text

Look at the multipart/alternative branch: if the HTML part is missing, or sits before the plain-text one instead of after it, clients show the text.

A message that arrived cut short

A missing closing boundary is counted as a problem, which separates a truncated download from a message that was assembled wrongly in the first place.

Working out what a message weighs

The decoded column next to the raw column shows what base64 costs — roughly a third more bytes on the wire than the attachment itself.

Questions

Is my message uploaded?
No. The work is done by the page in front of you, on your own hardware, so nothing about the message is transmitted while you inspect it. Once the page has loaded you can disconnect the network and it behaves identically.
I have an .eml file rather than pasted text — will that work?
Only if you open it in a text editor and copy the contents across, since this box reads text. EML Viewer takes the file itself, renders the message and can save the attachments out.
Can I download an attachment from one of the parts?
Not with this tool, which reports structure, encodings and sizes only. EML Viewer decodes the parts of an .eml and offers each attachment as a file to save.
Why are the sizes slightly different from the original file?
They are counted from the text you pasted. Line endings converted on the way to the clipboard, or an 8-bit body in a non-UTF-8 charset, will move the totals by a few bytes per line.
What do the two settings change?
Nothing you can see. They feed a text report of per-part headers and decoded body previews that the page never puts on screen, and Copy output copies the table rather than that report, so both controls are inert as the tool stands.
Are attached or forwarded messages expanded too?
Yes. When a part declares message/rfc822 the parser starts over on its contents, so the message inside gets a row of its own and so does every part beneath it, and an inner message wrapped in base64 or quoted-printable is decoded first. Nesting deeper than about 25 levels is left unexpanded — a multipart that deep says so in the problem list, while an over-deep forwarded message simply stops there without a warning.
Can it tell me whether SPF or DKIM passed?
No. It reads structure, not authentication. Email Header Analyzer traces the delivery hops and the authentication results, and DKIM Record Checker looks up the signing key itself.

Related tools