MSG Parser Options Compared: extract-msg, msgreader, Aspose, API
Try it now: extract email data to Excel, CSV, or JSON
Connect a Gmail or IMAP mailbox to parse new mail automatically, or paste an email below to test the converter now.
Create a free account to download. No credit card required.
If you need to parse Outlook .msg files in production, you have four realistic routes: an open source library in your own language, a commercial SDK, Outlook automation on a Windows box, or a hosted API that returns each file as a JSON record. The libraries are free and run offline, the SDK buys broad format coverage, and the API removes the parser from your codebase. Which one wins depends on how many files you get, what you need out of them, and who maintains the code a year from now.
This comparison is for the developer or tech lead who has just been handed a folder of .msg files, a client portal that accepts them, or an intake workflow where they arrive daily, and who has to pick something this week.
Parse .msg and .eml files with one API call
MailParse accepts an Outlook .msg or an .eml file at one endpoint and returns the sender, recipients, date, subject, body, attachment list and your named fields as JSON. See the EML and MSG parser API, or paste a sample message into the tool above to see the record first.
Why .msg files are harder to parse than .eml
An .eml file is MIME text. Every mainstream language ships something that can read it, and the hard parts are encodings and nested parts. An .msg file is a different animal. Outlook saves it as a Compound File Binary (the old OLE container format), and the message lives inside as a set of MAPI property streams: one stream for the subject, one for the plain text body, one for the HTML body, separate storages for each recipient and each attachment.
Three details catch most teams out:
- String properties come in two flavors. Newer files store text as Unicode, older or some third-party files store it as 8-bit text in a codepage that you have to look up and decode. Get this wrong and names with accents turn into mojibake.
- The sender may not have an SMTP address. Mail that moved inside an Exchange organization can carry an internal X.500 style address in the sender field, with the real SMTP address in a different property or missing altogether.
- Some messages only have an RTF body. Outlook can save the body as compressed RTF with no plain text or HTML copy. Reading it means decompressing the RTF and, for HTML mail, pulling the original HTML back out of it.
Every option below handles the first point. They differ a lot on the second and third, and that is where a quick prototype and a production parser part ways.
The options, compared
| Option | Language | Reads .eml too | Business fields | Where it leads |
|---|---|---|---|---|
| extract-msg | Python | No, pair it with the email package | You write them | Mature, active, handles RTF bodies and saves attachments, has a JSON output mode |
| msgreader (@kenjiuno/msgreader) | JavaScript, Node or browser | No, pair it with a MIME package | You write them | Runs client side, so files never have to leave the browser |
| Apache POI (HSMF) | Java | No, pair it with Jakarta Mail | You write them | Fits JVM shops already using POI for Office files |
| Aspose.Email | .NET, Java, Python and others | Yes | You write them | Widest format coverage, converts between MSG, EML and other formats, commercial license |
| Outlook automation | VBA, PowerShell or COM | Yes | You write them | Reads exactly what Outlook shows, but needs a Windows machine with Outlook installed |
| MailParse API | Any, over HTTPS | Yes, same endpoint and same JSON keys | Named custom fields by label or regex | No parser in your codebase, scoped tokens and an audit log per call |
No prices are listed here on purpose. Library licenses and SDK pricing change, so check each project page before you commit. The open source libraries cost nothing to download and everything in engineering time; the SDK and the API cost money and save some or most of that time.
Which MSG parser should I use in Python?
extract-msg is the default choice for Python. It opens the file, exposes sender, recipients, date, subject, body and attachments as attributes, can save attachments to disk, and has a command line mode that prints JSON. It also handles the compressed RTF case, which many smaller libraries skip. Two things to plan for: it reads only .msg, so you still need the standard library email package for .eml files and a mapping layer so both land in the same shape, and you should check its license terms against how you distribute your own software.
If you only need a quick look at a handful of files, extract-msg on a laptop is the fastest route and there is no reason to pay for anything. The case for something else starts when the files arrive every day, from people you do not control, and someone has to answer for the ones that fail.
How do I read an MSG file in Node.js or the browser?
Use @kenjiuno/msgreader. It is the maintained fork of the original msgreader package, parses the compound file in JavaScript, and returns the subject, body, recipients and attachment data. Because it has no native dependencies it also runs in the browser, which is useful when policy says client files must not be uploaded anywhere. You will still need a separate MIME package for .eml, and you will write the field extraction yourself.
When does a hosted MSG parser API make sense?
An API makes sense when the files are part of a paid workflow and parsing them is not your product. The usual signs: you receive both .msg and .eml and are tired of keeping two libraries in sync, you need business values such as a claim number or an order reference rather than just headers, or the parse has to be logged because the files are client records.
With MailParse's parser API you POST the file to one endpoint with a bearer token and get back a 201 response holding a record with from, to, cc, bcc, date, subject, body and the attachment list, plus a key for each custom field you asked for. A custom field is either a label, where the text after it on the same line becomes the value, or a regex whose first capture group does. The same call accepts .eml, so one mapping covers both formats, and the JSON shape matches the app's JSON export if part of the team would rather upload files by hand.
Be honest with yourself about the limits before you choose it. The API lists attachments by filename, type and size but does not return their bytes or read inside a PDF. It reads the plain text and HTML bodies Outlook saved; a message stored with an RTF body only will come back with an empty body, so run a sample of your own files through it first. And for Exchange-internal mail, check that the from field holds the address format you expect. These are exactly the checks you would run on any library, and a free test on real files settles them in minutes.
What should I test before choosing an MSG parser?
Test on your own worst files, not on a clean sample. Pull twenty .msg files from the real source, including the oldest, the largest, one forwarded chain, one with accented names, and one sent between two colleagues inside Exchange. For each option, check four things:
- Is the body present and readable, including messages that look empty in a quick preview?
- Is the sender a usable SMTP address or an internal Exchange path?
- Do names and subjects with non-English characters survive intact?
- Does the parser stay within memory on the biggest file, for example one carrying a 40 MB attachment?
Then add the one check that decides most build or buy calls: how long does it take to get the business value you care about into its own field, and who fixes it when a sender changes their template? For a library, that is your regex in your repository. For the API, it is a label or pattern in the request.
Who uses an MSG parser at scale
Most of the volume we see comes from three kinds of teams. Litigation support and eDiscovery staff receive correspondence as exported .msg files and need sender, recipients, date and subject in a review index before anyone reads a word; once the correspondence is indexed, an AI assistant for legal practitioners can take over the case file organization. Insurance and claims operations save adjuster email into claim folders and need the claim number and dates in the claims system. And software products that let their own customers upload saved emails need a parser that behaves the same on every file their users throw at it.
If what you actually need is a spreadsheet rather than JSON, the MSG to Excel converter does the same parse and writes rows, and the earlier comparison of MSG to Excel converter software covers the desktop tools that batch whole folders. For a broader look at parser APIs, webhooks and inbound email services, see the best email parser for developers.
Frequently asked questions
Can I parse an MSG file without Outlook?
Yes. An .msg file is a documented compound file format, so libraries such as extract-msg, msgreader and Apache POI read it on any operating system without Outlook installed. A hosted API such as MailParse also parses it from any language over HTTPS, returning the fields as JSON.
Can I convert an MSG file to JSON?
Yes. extract-msg has a JSON output mode for a single file, and the MailParse API returns every .msg or .eml file as the same JSON record, with from, to, cc, bcc, date, subject, body and attachments, plus any custom fields you define in the request.
Is there one parser for both MSG and EML files?
Among free libraries, usually not: most read one format, so you combine two and map both into one shape. Aspose.Email covers both inside your application under a commercial license, and the MailParse API accepts both at the same endpoint and returns identical keys.