What is an MSG file?

MSG is a binary format, meaningful only to a program that knows it. It is used for email.

The extension is .msg, and the full name is Outlook Message. Both matter less than what the file can hold, which is what the rest of this page is about.

Microsoft published it in 1997.

A format that has been readable for that long is a format worth trusting with something you want back in ten years.

It is written down and implementable, though the vendor decides what the next version looks like. In practice that is enough for the file to keep opening; it is not enough to be sure of it.

Microsoft Outlook reads it, and so do most programs of the same kind.

If a file will not open, the format is rarely the problem — it is more often that the program predates it. Converting to something older is the reliable way past that, and it is what the rest of this site is for.

No browser reads it.

That is the single most common reason to convert it: not that the format is bad, but that the place you want to show the file cannot read it.

MSG is meant to be handed over rather than worked in. Editing one is possible and rarely pleasant; the sane approach is to change the source and export again.

The recurring complaints: support outside its home ground is uneven.

None of these is a reason to avoid the format. They are the things worth knowing before you are surprised by one, which is a different claim and a more useful one.

This is why most people end up reading about the format. MSG is Outlook’s own file for a single message, and outside the Microsoft world very little opens it — double-clicking on a Mac or on a machine without Office typically produces nothing at all, or an editor showing a screenful of binary.

The quickest route to the contents is to convert the file with something that reads the format — which this site does not, so the tool has to come from elsewhere. A PDF gives you the message as it would print, readable on anything, and it is the right answer if the message has to be filed or forwarded to somebody else in the same position. Converting to EML gives you the message as a standard mail file, which any mail client will open — that is the better choice if you need to keep working with it rather than just read it.

An MSG is not text. It is a Microsoft compound file — a small structured container, the same underlying technology as an old .doc — holding the message as a set of named streams: sender, recipients, subject, body, HTML body, and each attachment as its own stream.

That structure is why the format is awkward outside Outlook. Reading it means understanding both the container and the property names Microsoft uses inside it, and the property names are the part that was never a public standard in the way RFC 5322 is. Tools that read MSG have implemented that work; a text editor never will.

MSG stores mailbox state as well as the message. Categories, flags, follow-up dates, read status, the sensitivity marking, and for meetings the whole appointment — attendees, responses, the recurrence pattern, the free-busy status.

None of that exists in EML, because none of it is part of the message that travelled over the wire. It is Outlook’s record of what the item means inside your mailbox. That is genuinely useful while it stays in Outlook, and it is exactly the part that has nowhere to go when the file is converted — a meeting request exported to EML becomes an email about a meeting rather than an item a calendar will accept.

If you have ever received an email whose only attachment was called winmail.dat, you have met the same design decision from the other side. Outlook can send a message in a Microsoft-specific encoding that packs formatting and attachments together, and a non-Outlook client that does not understand it shows the whole bundle as one meaningless file.

The cause is the same in both cases: Microsoft mail objects carry more than the standard describes, and the extra has to go somewhere. The fix at the sending end is to compose in plain text or HTML rather than Rich Text; at the receiving end, a converter that understands the format can extract the real attachments.

Legal and compliance teams handle these constantly, because Outlook is what corporations run and an exported message is what gets collected. The format is acceptable for that purpose — the internet headers are preserved inside it, so the routing trail that makes an email evidential is still there.

The complication is the bundle. Courts and clients want PDFs, so a collection of MSG files usually has to be converted, with the attachments extracted separately and paginated. Doing that conversion late, after the relevant messages have been identified, saves an enormous amount of work compared with converting the whole export first.

The attachments are inside the file, each as its own stream, and they are not compressed. What they are not is accessible by renaming the file or opening it in an archive tool — the compound-file structure is not a ZIP, however much it behaves like a container.

With Outlook, open the message and save the attachments normally. Without it, a converter that reads MSG will separate them out. If all you have is a text editor, you can often see enough of a filename inside the binary to know what is in there, which answers the question of whether it is worth pursuing.

If the archive has to outlive your Outlook licence, EML is the safer container: a public specification from 1982, readable by any client, and plain text underneath. Converting from MSG loses the mailbox state and keeps the message, which for an archive is the right side of the trade.

Keep MSG when the item is a meeting, a task or anything else where the Outlook-specific properties are the content rather than decoration around it. And keep the original alongside any PDF you produce — the PDF is one rendering, and only the source can be re-rendered when somebody asks a question the first rendering did not anticipate.