Updated October 2026
Both .msg and .eml files represent a single saved email, and both can contain the same basic information — sender, recipients, subject, body, attachments. But they're structurally unrelated file formats under the hood, which is why software that reads one often can't read the other without a dedicated parser.
.eml is essentially a saved copy of the raw MIME message format that email has used for transport since the early internet standards (RFC 5322 and related specs) — the same plain-text structure your email actually travels across the internet in. Because it's a documented, open, text-based format, almost every email client (Apple Mail, Thunderbird, Gmail, Outlook itself) can read a .eml file directly, often just by double-clicking it.
.msg is a completely different kind of file: a CFBF (Compound File Binary Format) container — the same general binary container format historically used for old Microsoft Office files like .doc and .xls — internally packed with binary MAPI property streams that encode the message's fields (sender, recipients, subject, body, attachments) in Microsoft's own internal data structures, not as readable text. This format isn't publicly documented by Microsoft in the way MIME is an open standard, which is why support for it outside Outlook itself has always depended on third-party, reverse-engineered parsers. See the CFBF format deep-dive for more detail.
| .eml | .msg | |
|---|---|---|
| Underlying format | Plain-text MIME (open standard) | Binary CFBF container with MAPI streams (Microsoft-specific) |
| Readable in a text editor? | Mostly yes — headers and plain-text body are human-readable | No — binary data, unreadable without a parser |
| Native support | Apple Mail, Thunderbird, most webmail, Outlook | Outlook only (natively); everything else needs a dedicated parser |
| Typical origin | Most non-Outlook clients' "save message" or "export" feature | Outlook's "Save As" or drag-and-drop-to-desktop feature |
Not by simply renaming the file extension — that only changes what name the file has, not its actual internal byte structure, so a renamed file will fail to parse correctly in software expecting the other format. Genuine conversion requires software that actually understands both formats: reading the binary MAPI structure out of a .msg file and re-encoding that same information as plain-text MIME to produce a valid .eml, or vice versa. This tool reads .msg files and can export the message body as plain .txt, but it doesn't currently produce a re-packaged .eml file — see the text export guide for what the export feature actually does.
Outlook remains extremely widely used in corporate and enterprise environments, and its default "drag an email to the desktop" or "Save As" behavior saves as .msg, not .eml, unless a user specifically changes that setting or uses a different save method. That's why .msg files are so common in business contexts — legal document exchanges, IT exports, forwarded corporate emails — even though .eml would be easier for the recipient to open if they're not also using Outlook.
If I have a choice, should I ask someone to send .eml instead of .msg? If they're able to choose the export format and you don't have Outlook, yes — .eml is more universally readable without any special tooling. Many people don't realize Outlook defaults to .msg and may not know how to change it, though.
Does this tool open .eml files too? No — this tool is specifically built as a .msg/CFBF parser. A .eml file is plain text and can typically be opened directly in a text editor or any standard email client without needing a specialized tool.
Which format preserves attachments better? Both formats can contain attachments; MIME (.eml) encodes them as base64-encoded text blocks within the plain-text file, while .msg stores them as separate binary streams within the CFBF container. Properly implemented readers for either format extract attachments correctly.