What is a MIME decoder, and what do all these headers mean?

Every email you receive is, underneath, a plain-text document that follows a strict structure defined by MIME (Multipurpose Internet Mail Extensions) and the older RFC 5322 message format. When you open the “raw source” or a saved .eml file, that structure becomes visible: a block of headers, a blank line, and then the body. This decoder splits any message you paste into those pieces — headers, the MIME tree, the transfer encoding and charset of every part, the decoded text/HTML, and each attachment — entirely in your browser. Nothing is uploaded to any server; the parsing runs on your own computer.

1. The overall shape of a message

A message has two sections separated by the first empty line:

Header-Name: header value Another-Header: another value (a folded continuation line) <blank line> The body starts here…

Headers describe the message: who sent it, when, the subject, and — crucially for MIME — how the body is encoded and structured.
The blank line is the boundary between headers and body. The very first empty line ends the header block.
The body is everything after it. For a modern message the body is usually not plain text but a MIME structure with several parts.

2. How headers are written

Two rules trip people up when reading raw source:

Folding. A long header can be split over several lines; every continuation line begins with a space or tab. When read, those lines are joined back into one value (“unfolded”).
Encoded-words (RFC 2047). Headers officially allow only ASCII, so non-English text and emoji are wrapped as =?charset?B?…?= (Base64) or =?charset?Q?…?= (a quoted-printable variant). For example =?UTF-8?Q?caf=C3=A9?= decodes to café. The decoder above shows the readable value; the raw value is what actually travels on the wire.

3. The header fields explained

These are the variables you will see at the top of almost any message. Not all are always present.

Addressing and identity

Header	What it means
`From`	The author shown to the reader — a display name and address, e.g. `Anna <anna@example.com>`. This is what your mail client displays; it is not proof of who really sent the mail (see SPF/DKIM below).
`To`, `Cc`	Primary and carbon-copy recipients. Purely informational headers — the real delivery is driven by the SMTP envelope, not by these.
`Bcc`	Blind carbon copy. Normally stripped before delivery, so you rarely see it in received mail.
`Reply-To`	Where replies should go if that differs from `From` (e.g. a “no-reply” sender pointing replies to support).
`Return-Path`	The envelope sender (the “MAIL FROM” address) where bounces are sent. Added by the receiving server and often differs from `From`.
`Sender`	The actual agent that submitted the message when it is not the author (mailing lists, “on behalf of”).
`Message-ID`	A globally unique identifier for this message, like `<a1b2c3@example.com>`. Used for threading and de-duplication.

Threading, dates and subject

Header	What it means
`Subject`	The topic line. Often an encoded-word when it contains non-ASCII characters.
`Date`	When the author sent the message, with a time-zone offset, e.g. `Wed, 9 Jul 2026 10:15:00 +0000`.
`In-Reply-To`	The `Message-ID` this message replies to — lets clients build conversation threads.
`References`	The chain of earlier `Message-ID`s in the thread.

Routing and authentication

Header	What it means
`Received`	A trace line added by each mail server the message passed through, newest at the top. Reading them bottom-up shows the delivery path and timestamps.
`DKIM-Signature`	A cryptographic signature that lets the receiver confirm the message was really sent by the domain and was not altered in transit.
`Authentication-Results`	The receiving server’s verdict on SPF, DKIM and DMARC checks (`pass`/`fail`). A quick way to judge whether a “From” is trustworthy.
`Received-SPF`	Whether the sending IP is authorised to send for the envelope domain.
`List-Unsubscribe`	For bulk/newsletter mail: the address or URL a client uses for one-click unsubscribe.

4. The MIME variables — how the body is built

These few headers control the whole structure of the body. They are the variables this decoder cares about most.

Variable	What it does
`MIME-Version: 1.0`	Declares that the message uses MIME. Practically always `1.0`.
`Content-Type`	The single most important variable: the media type of a part (`text/plain`, `text/html`, `image/png`, `application/pdf`, `multipart/*`…). It carries parameters after semicolons.
`charset`	A parameter of a text `Content-Type`: the character encoding of the text, e.g. `charset="UTF-8"`. Needed to turn bytes back into the right letters.
`boundary`	A parameter of a `multipart` type: a unique marker string. Each part starts with `--boundary` and the last one ends with `--boundary--`.
`Content-Transfer-Encoding`	How the part’s bytes were packed so they survive as 7-bit text on the wire (see the table below).
`Content-Disposition`	`inline` (show it in the message) or `attachment` (offer it as a file). Usually carries a `filename` parameter.
`name` / `filename`	The suggested file name of an attachment, in `Content-Type` and `Content-Disposition` respectively.
`Content-ID`	An identifier for an inline part (e.g. an image) so the HTML body can reference it with `cid:`.

The common multipart types

multipart/alternative — the same message in two forms: a text/plain fallback and a text/html version. The client shows the richest one it can.
multipart/mixed — a body plus attachments bundled together.
multipart/related — an HTML part together with the inline images it references by Content-ID.

These nest: a real message is often multipart/mixed containing a multipart/alternative (text + HTML) next to a PDF attachment. The decoder shows this as a numbered tree (1, 1.1, 1.2…).

5. Content-Transfer-Encoding values

Value	Meaning
`7bit`	Plain ASCII, nothing changed. The default when no encoding is given.
`8bit`	Raw bytes above 127 are used directly (needs an 8-bit-clean path).
`binary`	Arbitrary bytes, no line-length limits — rare in normal mail.
`quoted-printable`	Mostly-readable text where non-ASCII bytes become `=XX` hex (and `=` at end of line is a soft break). Good for text that is mostly English with a few accents.
`base64`	Any bytes re-coded into a safe 64-character alphabet, ~33% larger. Used for images, PDFs and other binary attachments.

The decoder reverses whichever of these was used, then applies the part’s charset so text comes back readable and attachments come back as their original bytes (which you can download).

6. A worked example

Press “Load a sample” above to load a small message and see it decoded. Its skeleton looks like this:

Subject: =?UTF-8?Q?Meeting_notes_=E2=80=93_caf=C3=A9?= ← encoded-word MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="OUTER" --OUTER Content-Type: multipart/alternative; boundary="INNER" --INNER Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ← text part ... --INNER Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 ← HTML alternative ... --INNER-- --OUTER Content-Type: text/plain; name="notes.txt" Content-Disposition: attachment; filename="notes.txt" Content-Transfer-Encoding: base64 ← attachment ... --OUTER--

Reading it: the outer type is multipart/mixed, so the body is “content + attachment”. Its first child is a multipart/alternative holding the plain-text and HTML versions of the same note; its second child is the notes.txt attachment. The Subject is an encoded-word that decodes to “Meeting notes – café”.

7. Privacy

Everything stays on your device. This tool parses the message with JavaScript in your browser — the raw email is never sent to us or anyone else, and nothing is stored. You can safely inspect private or sensitive messages.

Once you know which server a message came from, you can dig further: look up the domain’s MX Lookup, read how a server answers in the SMTP check with telnet guide, or check whether an address is deliverable with the Email Checker.

MIME Decoder