How to open a .pst file without Outlook

What a .pst actually is

A .pst — Personal Storage Table — is not a folder of messages. It is a single-file database, with its own allocation scheme, its own B-trees, and its own way of packing every message, attachment, contact and calendar entry into pages of a few kilobytes each. Microsoft published the structure as the [MS-PST] open specification, which is why reading one is possible at all, and the specification runs to a couple of hundred pages, which is why so few programs bother.

Two B-trees do the work. The node B-tree maps every object in the file to where its data lives; the block B-tree maps those data references to actual byte ranges on disk. On top of that sit the heap, and the property and table contexts — the structures that turn a pile of bytes into "this message has this subject, from this person, with these three attachments".

That is the reason a .pst cannot be opened by dragging it into a mail client that expects mbox or .eml. There is no line-by-line format to parse. You either implement the database or you do not read the file.

Why you have one, and why it is usually urgent

Almost nobody creates a .pst deliberately. They arrive three ways, and all three are the same story told at different speeds:

• Outlook was configured with a POP account, so every message ever received lives in one file on one machine and nowhere else.
• Somebody ran Outlook’s own archive or export, producing a .pst covering years, and then left the organisation.
• An IT department migrated a mailbox and handed the old one over as a file, in place of the mailbox it used to be.

What these have in common is that the file usually turns up at the worst moment — during a dispute, an audit, a handover, or after a person has left — and the machine that could open it is gone. That is why the question is asked in a hurry, and why the wrong answer is expensive.

The five real options

Install Outlook and open it. The only path with no fidelity risk at all, and often the fastest if a licence is already available. A .pst opens as a separate folder tree beside your existing mail; nothing is imported anywhere.

Import it into a mail client that supports it. A few desktop clients read .pst directly. This is genuinely useful when you want the mail in something you already use, and the thing to check first is whether the client reads the file or shells out to a converter — the second one is where losses creep in.

Convert it to something open. Tools exist that turn a .pst into mbox or a directory of .eml files, and the result is portable, greppable and future-proof. The cost is that conversion is where fidelity is lost: rich-text bodies, unusual encodings, embedded messages and non-mail items — contacts, calendar entries, tasks — are the usual casualties. Check a converted archive for those specifically, not just for the message count.

Use a dedicated viewer. Read-only tools that open the file and let you search and export individual messages. Good for finding one thing; less good for taking custody of an archive.

Read it programmatically. There are libraries in several languages that implement enough of [MS-PST] to walk the tree. Worth it if you have hundreds of files, and a poor use of a day if you have one.

If it is an .ost rather than a .pst

An .ost is the same database format doing a different job: it is the offline cache of a server mailbox, not a portable archive. That difference matters more than it sounds, in three ways.

First, Microsoft’s own tooling generally will not let you open an orphaned .ost — the supported path is to reconnect the account, which is exactly what you cannot do when the account is gone. Second, Outlook 2013 and later compress the larger data blocks inside an .ost with zlib, and that compression is not in the published structure. A reader that does not know about it opens the file, walks the trees successfully, and shows you an archive in which every message is empty. Third, an .ost’s folder hierarchy is usually not materialised the way a .pst’s is: the tables that would list the folder tree may simply not be there, and the tree has to be rebuilt from the node B-tree’s parent pointers instead.

Practical consequence: test any tool on your actual .ost before trusting it, and check message *bodies*, not just that folders and subjects appeared.

What to check before you trust the result

Whatever route you take, four checks catch nearly every silent failure:

• Message count per folder, against what Outlook reported if you can still get it. A tool that quietly skips what it cannot parse will be short.
• Bodies, not subjects. The zlib case above produces a perfect folder tree full of empty messages, and a spot check of subject lines will not find it.
• Attachments. Open a few. Attachment extraction is a separate code path from message parsing and fails separately.
• Non-mail items. Contacts, calendar entries and tasks live in the same file and are the first thing a mail-focused converter drops.

Keep the original, whatever you do

Copy the .pst somewhere safe before opening it with anything, and keep that copy after you have converted or imported it. A .pst is a database, and a database that a tool opened read-write once is a database that may have been changed. The file is also usually the only copy of what it contains — which is the whole reason the question is being asked.