What is an .ost file, and can you recover mail from one?

What it is for

When Outlook connects to Exchange, Microsoft 365 or an IMAP account in cached mode, it keeps a local copy of the mailbox so the application works while the network does not. That copy is the .ost. The server holds the authority; the .ost holds a replica.

Because it is a replica, it is designed to be disposable. Delete it and Outlook rebuilds it from the server on the next connection. That design assumption is behind every difficulty in this article: nothing about an .ost was built for the case where the server copy is the one that has gone.

How it differs from a .pst

Structurally they are close cousins — the same node and block B-trees, the same heap and property contexts. Practically they are different objects:

• A .pst is a portable store. It is meant to be moved, backed up and opened elsewhere, and Outlook will open one on any machine.
• An .ost is a cache. It is bound to the profile that created it, and Outlook will not simply open a loose one you were handed.

There are two further differences that only appear when you try to read one with something other than Outlook, and both surprise people who assume the formats are interchangeable.

The compression nobody documents

Outlook 2013 and later compress the larger data blocks inside an .ost with zlib. This is not part of the published [MS-PST] structure, so a reader written faithfully from the specification will parse the file, walk its trees, resolve its folders — and hand you an archive in which every message body is empty.

This is the single most common reason a tool "works" on a .pst and produces nothing useful from an .ost. If you are evaluating software for this job, open a message body. Not the folder list, not the subject line: the body.

The folder tree that is not there

In a .pst, the hierarchy and contents tables that describe the folder structure are generally present. In an .ost they are frequently not materialised — a file with hundreds of folders may carry a handful of hierarchy tables between them, because the client expects to get that structure from the server rather than from the file.

A reader that depends on those tables therefore shows you a fraction of the folders. The structure is still recoverable: every node in the node B-tree carries a parent pointer, and those are always complete, so the tree can be rebuilt from the bottom up. It is simply a different algorithm from the one the specification implies, and a tool either does it or does not.

And where a view table does exist, it may carry no subject column at all — so a reader that trusts it renders a list of blank rows over perfectly good messages.

Getting mail out of an orphaned .ost

In rough order of how much you should try them:

• Reconnect the account, if it exists at all. If the mailbox is alive anywhere, resynchronising is the answer and everything below is unnecessary.
• Ask for a server-side export. An administrator can usually export a mailbox to .pst, which puts you in the much better-supported case covered by the companion article.
• Use a tool that reads .ost directly. Some do, including free ones. Test it on the actual file for the two failure modes above before believing the result.
• Convert to .pst first. Widely offered, and it adds a conversion step whose losses you then cannot see, so prefer a direct reader when one works.

Whatever you use, copy the file first and work on the copy.

One thing worth saying out loud

An .ost you have been handed is somebody’s mailbox. Even when reading it is entirely legitimate — a departed employee, an estate, a dispute where you are entitled to the contents — it is worth being deliberate about where the file goes. An upload to a web-based converter is a copy of an entire mailbox on somebody else’s server, and that is a different act from opening a file on your own machine, whatever the tool is called.