MIME File Documentation

Summary

A MIME-encoded message file is a message, almost always an email, saved in the internet's standard on-the-wire text form: RFC 5322 headers, a blank line, then a MIME body whose parts and attachments are encoded as text. A .mime file is structurally the same as an .eml file (MIME type message/rfc822). You do not need a special viewer: rename it to .eml and open it in Thunderbird, Apple Mail or Windows Mail, or read the raw text in any editor.

Technical details

FeatureValue
Full nameMIME-encoded message file (RFC 822 / MIME)
File extension.mime
MIME typemessage/rfc822
Format typePlain-text message: headers + MIME body
Character encodingUS-ASCII headers; body parts may use any charset, declared per part
Content-transfer-encoding7bit, 8bit, quoted-printable or Base64 per part
DeveloperIETF standard (MIME working group)
Base message formatRFC 822 (1982), now RFC 5322
MIME standardRFC 2045–2049 (1996)
Open standardYes — fully specified IETF standard
Magic numberNone — plain text; conventionally starts with a header line
Equivalent extension.eml (same format; rename works)
StructureHeaders, blank line, one or more MIME parts split by boundary strings
Also wrapsSaved MHTML web archives / raw MIME parts (same RFC 2045 envelope)
Opens inMozilla Thunderbird, Apple Mail, Windows Mail, Outlook, any text editor
Related extensions.eml, .mht, .mhtml, .emlx, .msg, .mbox
Specificationrfc-editor.org/rfc/rfc2045
Structure at a glance

A .mime file is plain text with no byte signature. It opens with header lines (From:, To:, Subject:, Date:, MIME-Version: 1.0, Content-Type:), then a single blank line, then the body. A multipart message declares Content-Type: multipart/mixed; boundary="XYZ" and separates each part with a line of two hyphens plus that boundary (--XYZ). Binary attachments appear as text under Content-Transfer-Encoding: base64. Because everything is text, the whole message is readable in any editor, though Base64 parts look like blocks of gibberish until a mail client decodes them.

What is a MIME file?

MIME stands for Multipurpose Internet Mail Extensions, the set of IETF standards (RFC 2045 through 2049, published in 1996) that extend the original 1982 internet message format so a message can carry more than plain US-ASCII text. A file with the .mime extension is a complete message, almost always an email and occasionally a saved news article or a web archive, stored in exactly the on-the-wire text form a mail server would transmit. Its MIME type is message/rfc822.

Structurally it is identical to an .eml file: a block of headers, a single blank line, then a body. The two extensions are interchangeable, so the most reliable way to open a .mime is to rename it .eml and let a mail client parse it. The extension turns up when a mail or news client, a server, or an export tool writes a message with that suffix instead of .eml. Everything below is about how the MIME envelope actually encodes a message, because that structure, not any special file format, is what a .mime file contains.

RFC 5322 headers and the header/body split

The base message format is defined by RFC 5322 (which revised the historic RFC 822). A message is a sequence of header fields, then one empty line, then the body. Each header field is a name, a colon, and a value: From:, To:, Subject:, Date:, Message-ID:. Lines end with a carriage return and line feed (CRLF, bytes 0D 0A), and a long field can be folded across several physical lines by starting the continuation with whitespace.

From: Alice <alice@example.com>
To: Bob <bob@example.net>
Subject: Quarterly report
Date: Tue, 22 Jul 2026 09:14:00 +0000
Message-ID: <a1b2c3@example.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_boundary_42"
                                 <-- one blank line separates headers from body -->

The blank line is load-bearing: everything before it is metadata, everything after it is content. Two headers do the MIME work. MIME-Version: 1.0 announces that the message follows the MIME rules, and Content-Type declares what the body is. Without MIME-Version, a body is treated as plain RFC 822 text. The trace headers a message accumulates in transit, chiefly the stack of Received: lines and any Authentication-Results recording SPF, DKIM and DMARC checks, are also plain text here, which is why you can read them in an editor to judge whether a sender is genuine.

Content-Type, boundaries and multipart trees

MIME's central idea is that a body has a media type written as type/subtype: text/plain, text/html, image/png, application/pdf. When a message needs to hold several of these at once, its top-level type is one of the multipart types, and the body becomes a container of parts, each with its own headers and its own Content-Type.

The parts are separated by a boundary string chosen by the sending software and declared in the Content-Type parameter boundary="...". Each part begins with a line of two hyphens followed by the boundary; the message ends with the boundary bracketed by two hyphens on each side.

Content-Type: multipart/mixed; boundary="=_boundary_42"

--=_boundary_42
Content-Type: text/plain; charset="utf-8"

The report is attached.
--=_boundary_42
Content-Type: application/pdf; name="report.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="report.pdf"

JVBERi0xLjcKJeLjz9MKMSAwIG9iago8PC9U... (Base64 continues)
--=_boundary_42--

Three multipart subtypes matter. multipart/mixed is a body plus attachments. multipart/alternative holds the same content twice, typically a text/plain and a text/html version, and the client shows whichever it prefers. multipart/related groups an HTML part with the inline images it references, each image tagged with a Content-ID that the HTML links to via a cid: URL. Because parts can themselves be multipart, a real message is a small tree: an alternative pair nested inside a related group nested inside a mixed container with the attachments.

Content-Transfer-Encoding: Base64 and quoted-printable

A message travels over channels that were historically restricted to 7-bit text, so any part that contains 8-bit or binary data must be re-expressed using printable characters. The Content-Transfer-Encoding header on each part says how, and there are two encodings you will actually see.

Base64 maps every 3 bytes of input to 4 ASCII characters drawn from a 64-symbol alphabet (A–Z a–z 0–9 + /), padding with =, and wraps the output at 76 characters per line. It is used for genuinely binary parts: images, PDFs, any file attachment. The 4-for-3 ratio is why an emailed attachment is roughly 33% larger than the original file. Quoted-printable leaves ordinary ASCII untouched and escapes only the awkward bytes as = followed by two hex digits (a non-breaking space becomes =A0), with = at end of line marking a soft line break. It suits mostly-text parts, such as an HTML body or text in an accented language, because most of the content stays human-readable. The remaining values, 7bit, 8bit and binary, mean the part was not transformed at all. Decoding these encodings back to the original bytes is exactly what “saving the attachment” does in a mail client.

MIME, EML and the MHTML web-archive case

Because a .mime file and an .eml file are both just RFC 822/MIME messages, converting between them is a rename with no change to the bytes. The same envelope is also reused outside email. When a browser saves a page as a “web archive,” it writes an MHTML file (.mht/.mhtml): a multipart/related MIME message whose first part is the page's HTML and whose remaining parts are the images, stylesheets and scripts, each bound by Content-Location or Content-ID. A raw MIME part saved on its own can likewise land with a .mime name. In every case it is the same RFC 2045 structure, wrapping web content instead of a letter, which is why one text editor and one set of rules read all of them.

References