Only one of the four is a standard anyone agreed on. The other three are formats somebody needed, which is why converting between them works in some directions and is a waste of effort in others.
EML — one message, as it travelled
An .eml file is a message in the form defined by RFC 5322: header lines, one blank line, then the body. If there are attachments or two versions of the body, MIME divides the body into parts separated by a boundary string that the headers declare.
From: Rana <rana@supplier.example>
To: you@example-mail.net
Subject: Invoice 4471
Date: Tue, 4 Aug 2026 09:14:19 +0000
Content-Type: multipart/mixed; boundary="b1"
--b1
Content-Type: text/plain; charset=UTF-8
Attached, as agreed.
--b1--It is text, and that is the whole reason it matters. You can open one in a text editor and read most of it. Every mail client on every platform accepts one. It is very close to what actually crossed the wire, which is why it is the right thing to keep when a message has to be preserved rather than merely stored.
What it holds: the complete header block, the body in each version the sender supplied, and the attachments encoded as text inside the same file.
What it does not hold: anything about your relationship to the message. Read or unread, which folder it was in, what you flagged it as — none of that is part of a message, because none of it travelled with it.
MSG — one message, in Outlook's cupboard
An .msg is what Outlook writes when you drag a message to the desktop. It holds one message and it is not text.
The container is Compound File Binary Format — Microsoft's general-purpose structured storage, the same thing that underlies an old .doc. It behaves like a small file system inside a single file: named storages, streams within them, a directory to find them by. Each MAPI property of the message gets its own stream, named by property tag.
The consequence is that an .msg can carry things a message has no field for, and mostly does:
- Categories and follow-up flags. Colour categories, a flag with a due date, a reminder. These are Outlook's, not the message's.
- Voting and tracking. The response buttons and the record of who clicked what.
- An RTF body. Outlook stores a compressed RTF version alongside the plain and HTML ones, and it is the one that holds Outlook's own formatting.
- Exchange addresses. This is the one that bites. Mail sent between colleagues on the same Exchange organisation often records the sender as an X.500 directory name —
/o=ExchangeLabs/ou=.../cn=Recipients/cn=...— rather than as an email address, because internally it never needed one. Take that message out of Outlook and there may be no SMTP address in it to show.
MBOX — many messages, end to end
An .mbox is the simplest idea in this article: put the messages in a file, one after another. It is what Thunderbird stores a folder as, what Apple Mail exports, and what Google hands back.
What separates one message from the next is a line beginning with the five characters From — From and a space, with no colon. It is not a header, despite looking like one, and it is not part of the message.
From rana@supplier.example Tue Aug 4 09:14:19 2026
From: Rana <rana@supplier.example>
Subject: Invoice 4471
Attached, as agreed.
From omar@client.example Tue Aug 4 11:02:55 2026
From: Omar <omar@client.example>
Subject: Re: Invoice 4471Two From lines at the start of each message, one with a colon and one without, doing entirely different jobs. That is the format.
It also contains its own oldest bug. If a line in someone's message body happens to begin with From — the start of a sentence, a quoted line — a naive parser reads it as the start of a new message and splits one message into two. The conventional fix is to prefix such lines with > when writing and strip it when reading, and there are several mutually incompatible conventions for doing so. A parser that does not also check that a plausible header block follows will get this wrong on real archives.
What it does not hold: folders. An mbox is one flat sequence, so a mailbox with a folder tree exports as either one file per folder or one very large file with the structure gone.
PST — a mailbox, as a database
A .pst is a different kind of object entirely, and this is the distinction that saves the most wasted time: it is not a message file at all.
It is Outlook's Personal Storage Table — a database with B-tree indexes, holding a folder tree, the messages in each folder, and also the contacts, calendar entries, tasks, notes and rules. It is designed for random access: Outlook opens one and reads the message you clicked without walking the file.
Two variants exist. The old ANSI one, from Outlook 97 to 2002, stops working at 2 GB and tends to corrupt as it approaches it; the Unicode one, from 2003 onwards, is what anything current writes. The near-identical .ost is the offline cache of a server mailbox and is bound to the profile that created it, which is why an .ost found on an old machine is usually not recoverable in the way people hope.
One thing worth being precise about: the password Outlook offers on a .pst is not encryption in any meaningful sense. Nor is the "compressible encryption" option, which is a fixed byte substitution — every byte looked up in one published 256-entry table, the same table for everybody, with no password anywhere in it. It is in section 5.1 of the format specification, which is how anyone who wants to read it does. The name is the clue: it is called compressible because it leaves the data compressible, and something that survives a ZIP intact was never encrypted. Do not treat a .pst as a protected file.
What converts to what
Read this as a hierarchy of shape rather than of richness. Splitting a pile into documents is easy; turning a document into a database entry is not conversion at all.
- MSG → EML. The direction that works and the one people need. Recipients, subject, date, body and attachments all have a home in a standard message. Doing it is what makes the file readable outside Outlook. What does not survive: categories, flags, voting records, the RTF body's exact formatting, and an Exchange X.500 sender where no SMTP address was recorded.
- EML → MSG. Possible and not worth doing. It means writing a compound file and inventing MAPI properties for fields that were never set, and Outlook opens .eml directly anyway. The only real reason to want it is to get a message back into a specific Outlook folder, and importing does that without a conversion.
- MBOX → EML. Not a conversion — the messages inside an mbox are already in .eml form, so splitting an archive is finding the boundaries and writing out what is between them. Nothing is decoded or rewritten. The only thing lost is the ordering the container gave you.
- EML → MBOX. Concatenation, with one caveat: the
Fromseparator has to be synthesised, because it was never part of the message. Tools invent it from the sender and the date, and different tools invent it slightly differently. - MBOX → CSV. An index rather than a copy. A row per message — from, to, date, subject, size — which is what you want for counting and sorting a large archive, and is not a backup of it.
- PST → anything. An extraction, not a conversion, and the one job here that genuinely needs software built for it. Outlook itself will export a folder, which is the least painful route. Note also that a .pst holds calendar entries, contacts and rules that have no representation as a message at all — whatever comes out will be messages plus a set of files in other formats.
Which to keep
EML for a message that matters on its own — a contract, a notice, anything that might have to be produced later. It is text, it is standard, and it will still open in twenty years, which is not a claim any of the other three can make with the same confidence.
MBOX for a whole mailbox, because it is the only portable option. Expect the folder structure to be gone and check what the export actually contains before deleting anything.
MSG only while the message is staying inside Outlook. The moment it has to be sent to somebody or filed anywhere else, convert it.
PST as an Outlook artefact rather than an archive. It is a database format tied to one program, it has a size at which it degrades, and its password is not protection.
All four are read from their contents rather than their extension by the viewer here — worth knowing, because a file saved with the wrong extension is common and because none of this needs to leave your machine to be read.