EML File Documentation

Summary

An E-Mail Message file (.eml) is a single saved email — its headers, body and any attachments — stored as plain text in the internet standard email format (RFC 5322 headers plus MIME). Its MIME type is message/rfc822. It is exactly what an email looks like “on the wire”, so it opens in Thunderbird, Apple Mail or Windows Mail, and you can even rename it to .txt to read the raw text.

Technical details

FeatureValue
Full nameE-Mail Message (RFC 822 / MIME)
File extension.eml
MIME typemessage/rfc822
Format typePlain-text email message (headers + MIME body)
DeveloperIETF standard; extension popularised by Outlook Express
IntroducedRFC 822 (1982); MIME RFC 2045 (1996)
Standard / specRFC 5322 (message format); RFC 2045–2049 (MIME)
Open standardYes
EncodingUS-ASCII text; 7-bit, quoted-printable or Base64 bodies
Magic numberNone — plain text; conventionally starts with a header line
Line endingCRLF (0D 0A) per RFC 5322
StructureHeader block, blank line, then body
MultipartMIME boundaries separate text, HTML and attachments
AttachmentsBase64-encoded inline within the same file
HoldsOne message (versus .mbox/.pst = many)
Readable asAny text editor; drag into a web browser
Related extensions.msg, .mbox, .emlx, .mht, .p7m
Specificationrfc-editor.org/rfc/rfc5322
Structure at a glance

An .eml has no binary magic signature — it is plain US-ASCII text and can be opened in any editor. It conventionally begins with a header field such as Return-Path:, Received:, From: or Date:, or with a Unix mailbox From  separator line. The layout is fixed by RFC 5322: a block of Name: value headers, one blank line (a bare CRLF), then the body. When the message carries HTML or attachments, the body is split by MIME boundary markers into parts, each with its own Content-Type and Content-Transfer-Encoding (typically base64).

What is an EML file?

An .eml file is a single email message saved as a file. It stores the message in the internet standard email format defined by RFC 822 (1982) and its current successor RFC 5322, with MIME (RFC 2045 onward, 1996) handling attachments and formatted content. The extension was popularised by Microsoft Outlook Express in the late 1990s, but the format itself is open and universal: an .eml is byte-for-byte what an email looks like as it travels between mail servers.

The whole file is plain text. There is a block of headers, a blank line, then the body, and any HTML formatting, inline images and file attachments are encoded into that same text using MIME. Because it holds exactly one message in a standardised, human-readable form, an .eml is highly portable — any mail client can open it, and it can still be read decades later, unlike proprietary mailbox stores. The sections below cover how the headers, MIME parts and encodings are actually laid out.

The header block, the blank line and the body

RFC 5322 fixes the top-level shape of every message: a sequence of header fields, then a single empty line, then the body. That empty line — a bare CRLF with nothing before it — is structurally load-bearing: it is the one and only separator between headers and content, so the first blank line in the file marks where the body begins.

From: Alice <alice@example.com>
To: Bob <bob@example.org>
Subject: Lunch
Date: Tue, 21 Jul 2026 12:04:11 +0000
Message-ID: <a1b2@example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
                              <-- this blank line ends the headers
Hi Bob, are we still on for lunch?

Each header is a field name, a colon, and a value, one logical line each (long values may be “folded” across several physical lines with leading whitespace). Some headers are written by the author — From, To, Subject, Date — while others are added in transit. Every mail server that relays the message prepends its own Received: header, so those stack newest-first at the top and record the delivery path. Message-ID uniquely names the message, and authentication results (DKIM-Signature, and SPF/DMARC verdicts recorded in Authentication-Results) let a reader judge whether the sender is genuine. This is why an .eml is used as evidence: the raw headers preserve the full routing and signing history that a rendered email hides.

MIME: multipart boundaries and nested parts

A plain-text note needs nothing more than the structure above. The moment a message carries HTML formatting, inline images or attachments, MIME takes over and the body becomes a tree of parts. The top-level Content-Type declares a multipart/* type and, crucially, a boundary string; that exact string, prefixed with two hyphens, then separates each part, and the same string with two trailing hyphens closes the set.

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

--B1
Content-Type: multipart/alternative; boundary="B2"

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

Plain-text version of the message.
--B2
Content-Type: text/html; charset="utf-8"

<p>HTML version of the <b>message</b>.</p>
--B2--
--B1
Content-Type: application/pdf; name="invoice.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="invoice.pdf"

JVBERi0xLjQKJc...  (Base64 bytes)
--B1--

Two multipart subtypes do most of the work. multipart/alternative holds the same content twice — a text/plain version and a text/html version — and the client shows whichever it prefers, which is how one file serves both a formatted and a fallback view. multipart/mixed bundles the message together with attachments as sibling parts. The parts nest: an alternative group commonly sits inside a mixed group, exactly as above. Because the whole tree is delimited by the plain-text boundary strings, a parser walks it purely by scanning for those markers.

Content-Transfer-Encoding: fitting binary into text

An email body historically had to survive channels that assumed 7-bit US-ASCII, so binary data cannot be placed raw into an .eml. Each MIME part declares a Content-Transfer-Encoding that says how its bytes were made text-safe. 7bit and 8bit mean the content is already plain text. quoted-printable keeps mostly-ASCII text readable while escaping the occasional non-ASCII byte as =XX hex. base64 re-encodes arbitrary binary — a PDF, a JPEG, a Word document — into a run of 64 safe characters, expanding the data by about a third. This is why an attachment inside an .eml appears as a long block of seemingly random letters: it is the file, Base64-encoded. A mail client reverses the encoding to reconstruct the exact original bytes when you save the attachment, which is the decoding a text editor cannot do for you.

EML versus MSG, mbox and PST

Several email file types are easy to confuse, and the difference is structural. An .eml is one message in open plain-text MIME, readable anywhere. Microsoft’s .msg is also one message, but it is a proprietary binary format (an OLE compound file) that carries Outlook-specific properties and is not human-readable. .mbox and .pst are whole mailboxes: an mbox file concatenates many messages in a single text file, each introduced by a From  line, while a PST is Outlook’s binary database of folders and messages. EML is the single-message lingua franca that virtually every mail program can import or export, which is why moving one message between systems, or archiving it independently of any account, is almost always done as .eml. Converting an .eml to PDF (open it in a client and print to PDF) is the usual step for keeping a message as a fixed record.

Frequently asked questions

How do I open an EML file without Outlook?

Because an .eml is standard MIME text, almost any mail client reads it: Mozilla Thunderbird on any OS (File › Open Saved Message, or drag it in), Apple Mail on macOS by double-click, or the built-in Mail app on Windows. For a quick look at just the content, rename the file to .txt and open it in a text editor, or drag it into a web browser — the raw headers and body are plain text.

Where are the attachments inside an EML?

They are stored in the file itself, as MIME parts marked Content-Disposition: attachment and encoded in Base64 — the long block of letters after the part’s headers. A mail client decodes that Base64 back into the exact original file when you choose to save the attachment. That decoding is why opening the .eml in a client, rather than reading it as text, is the way to get the attachments out.

References