Email archive formats, explained

PST · OST · OLM · MBOX · EML · MSG — what each one actually is, and how to get your mail out of it.

Six formats cover almost every email archive a person runs into. They are not variations on a theme: two are proprietary databases, one is a ZIP of XML, one is a text file, one is a single message as text, and one is a single message as a compound binary. Which one you have determines what can open it and what converting it will cost you in fidelity.

This page is a working reference rather than a sales pitch. We wrote a parser for each of these formats to build Mailward, and the details below — including the ones that are awkward for us — are what we learned doing it.

The short version

PST — a database, not a folder of emails

A PST (Personal Storage Table) is a single-file database. Microsoft publishes its layout as the [MS-PST] specification: a node database built from B-trees holding blocks, with a property layer on top that stores each message as a set of typed properties.

The consequence catches people out. There is no email text sitting inside a PST waiting to be copied — a reader has to walk the B-trees, resolve each message's property set, and then reconstruct a standards-compliant RFC 5322 message from those properties. That is why "just rename it" never works, and why converting a PST is a genuine rewrite rather than a repackage.

PST exists in two incompatible variants. The ANSI variant, written by Outlook 97 through 2002, tops out at 2 GB and was notorious for corrupting archives that grew past that ceiling. The Unicode variant arrived with Outlook 2003 and is what essentially every modern .pst uses. A reader that only handles one will fail confusingly on the other.

One thing no viewer can do: repair a damaged PST. If Microsoft's own scanpst cannot open a file, neither can we or anyone else — recovery is a different problem from reading. Open a PST file without Outlook →

OST — the same format, locked by the application

An OST is structurally the same container as a PST; [MS-PST] describes both. The difference is purpose: an OST is the offline cache Outlook maintains for one specific mailbox, created automatically rather than exported on purpose.

The lock people hit is not in the file — it is in Outlook. An OST is bound to the profile and account it belongs to, and Outlook will not open one it cannot associate with a live account. Lose the tenant, leave the company, or decommission the server, and a perfectly healthy file full of your mail becomes unopenable by the only app that normally reads it. Renaming .ost to .pst does not help: Outlook inspects the file, not the extension.

A reader that parses the container format directly never consults that account association. Worth being explicit about what that means: it is a technical capability, not an entitlement. Only open mailbox data you have the right to access. Open an OST file →

OLM — a ZIP of XML that only one app writes

OLM is the least documented format here, so here is what it actually is. An .olm file is a ZIP container. Inside, each message is its own small XML document whose elements carry an OPF prefix — OPFMessageCopySubject, OPFMessageCopyFromAddresses, OPFMessageCopyHTMLBody and so on. Folder hierarchy is expressed by where those documents sit in the archive, and attachments are referenced out of the message XML by an OPFAttachmentURL pointing at another file in the same ZIP.

There is one trap worth knowing if you ever parse one yourself. OLM writes timestamps as UTC but omits the zone suffix entirely, so a value looks like 2022-05-26T17:55:40 with no trailing Z. Parse it as local time and every date in the archive silently shifts by your offset — which is the single most common way an OLM conversion goes quietly wrong. We validated both the element semantics and the timestamp handling against an independent implementation before trusting ours.

Because it is a ZIP of XML rather than a proprietary binary database, an OLM is in some ways easier to read than a PST. The obstacle was never technical difficulty — it is that only Outlook for Mac ever bothered. Windows Outlook will not open one, Apple Mail will not import one, and the commercial converters filling the gap mostly want $40 or your uploaded mailbox. Open an OLM file →

MBOX — simple, with one sharp edge

MBOX is one plain-text file holding every message in a folder, each introduced by a line beginning with the five characters "From " — the From_ line. That simplicity is why nearly every mail client imports it.

The sharp edge follows directly: if a bare "From " at the start of a line marks a new message, then a body line that genuinely starts that way will split the mailbox in the wrong place unless it is escaped. The variants exist entirely to disagree about how to handle this — mboxo escapes nothing reliably, mboxrd prefixes such lines with >, and mboxcl/mboxcl2 use a Content-Length header instead. Mailward writes mboxrd, because that is what Thunderbird and Apple Mail expect.

MBOX is also what Google Takeout hands you for Gmail: one file, no folder tree (Gmail has no folders), with labels preserved as an X-Gmail-Labels header and threading preserved through ordinary References and In-Reply-To headers. Open an MBOX file →

EML — one message, exactly as it travelled

An .eml file is a single message serialised the way it moved across the network: RFC 5322 headers, a blank line, then a MIME body per RFC 2045. Nothing wraps it and nothing indexes it.

That makes EML the natural unit for review and evidence work — one message is one file, so it can be numbered, hashed, and handed on without carrying the rest of the mailbox with it. It is also where you go to read a message's Received: chain, which is the closest thing email has to a chain of custody. Read it bottom-up: the lowest Received: header is the first server that touched the message, the top one is the last. Reading it the other way round is a common way to reach a confidently wrong conclusion about a forged sender. Open an EML file →

MSG — one message in a CFBF container

A .msg is Outlook for Windows' way of saving one item as a file — drag a message onto the desktop and this is what you get. Unlike EML, it is not text at all: it is a CFBF/OLE2 compound file, the same container old Office documents use, holding a miniature filesystem of storages and streams with one typed MAPI property per stream. The subject, each recipient, and each attachment live in their own named streams.

Two properties routinely mislead people. The stored sender address in corporate mail is often an Exchange X.500 distinguished name (/O=ORG/OU=…), not an email address — the usable SMTP address sits in a separate property. And the internet header block (PR_TRANSPORT_MESSAGE_HEADERS) exists only on messages that arrived from outside: a .msg saved from a sent folder never had headers, so a viewer showing none is reporting a fact, not failing. Older ANSI-variant files add a third trap — their strings are encoded in a Windows codepage the file only hints at through codepage and locale properties, which is why naive parsers turn a Japanese subject into mojibake. Open a MSG file →

Which format should you convert to?

If the mail needs to live in another mail client — Thunderbird, Apple Mail, a Gmail import — convert to MBOX. It is the format those apps import natively, and one file per folder keeps the structure you already had.

If each message has to stand alone — discovery, review sets, evidence, or moving a handful of specific messages — convert to EML. One file per message is the whole point.

What you cannot sensibly convert to is PST. Writing a valid PST means implementing the [MS-PST] database format as a writer, and the only reliable producer of PST files is Outlook itself. Any tool promising to write one deserves scepticism; Mailward does not claim to and never will.

What gets lost in conversion — honestly

Every format change loses something, and the useful question is what. Moving from a property-database format (PST, OST) or a structured XML archive (OLM) into MIME means each message is rebuilt rather than copied, so it is worth knowing where the edges are:

• Headers and body text reconstruct faithfully — this is the part standards cover well.
• Attachments are the usual casualty in careless converters. A faithful export re-embeds them as base64 MIME parts, which is what Mailward's EML and MBOX output does — each exported message is a complete, standalone MIME document with its files inside. Separate per-message saving and whole-archive ZIP extraction remain for when you want files without mail.
• Outlook-specific properties — categories, flags, some calendar and contact fields — have no MIME equivalent and do not survive. No converter fixes this; the target format simply has nowhere to put them.
• Timestamps survive if the reader interprets the source correctly. See the OLM note above for the classic failure.

Why do this in a browser at all?

Email archives are among the most sensitive files a person owns, and the conventional options for opening one are to install and license Outlook, or to upload years of private correspondence to a free online converter. Modern browsers make a third option possible: the File API hands a local file to a Web Worker, the parsing happens on your own machine, and nothing is transmitted. You can load the page, disconnect from the network, and keep working.

The honest trade-off is headroom. A native application has memory a browser tab does not, which is why Mailward streams PST and OST files in pages rather than loading them whole — and why the MBOX reader, which does hold its parsed mailbox in memory, will feel slow on a very large Takeout export on a low-RAM machine.

Try it on your own file → · About Mailward · Corrections welcome