How to open a winmail.dat file

Why you received one

Outlook can send mail in Rich Text Format, a Microsoft-only flavour that standard internet mail has no way to express. When it does, Outlook bundles everything that does not fit — the formatting, and every attachment — into a single blob called TNEF, short for Transport Neutral Encapsulation Format. Another Outlook on the receiving end unpacks it silently and you never learn it happened.

Anything else — Gmail, Apple Mail, Thunderbird, a phone, a ticketing system, an archive — does not know how, so it hands you the raw blob under the name Outlook gave it: winmail.dat. Two things follow from that:

• It is not your fault and not the sender's fault. It is a setting on one message, or on one Outlook contact entry, that neither of you probably knows exists.
• Your attachments are not lost. They are inside the file. This is the important part, and it is the reason a winmail.dat is worth opening rather than replying to ask for a resend.

Open it here

1. Save the winmail.dat out of the message.
2. Drop it on the viewer.
3. Read the message, and download the attachments individually or as a ZIP.

Parsing runs in your browser. Nothing is uploaded, which matters more here than usual: a winmail.dat almost always turns up in a thread that was never meant to leave the company, and the obvious alternative — a converter site that wants you to upload it — means posting exactly that to a server you know nothing about.

What comes back, and what does not

The subject, the sender, the date, the formatted body and every attachment are all stored in the file and all come back.

The recipient list does not, and no tool can recover it from this file. TNEF is an attachment inside a carrying message, and To, Cc and the internet headers belong to that carrying message rather than to the attachment. If you need them, they are in the mail you received the winmail.dat with — open its headers there. A viewer that shows you a recipient list from a winmail.dat is guessing.

What is actually inside the file

A winmail.dat is not a compressed archive and not a .msg. It is a flat stream of length-prefixed attributes, defined by MS-OXTNEF, and it opens with a four-byte signature: 0x223E9F78, little-endian. That signature is how a reader identifies one regardless of what the file has been renamed to — which matters, because mail gateways rename these constantly.

After the signature the file is a sequence of records, each carrying a level byte saying whether it belongs to the message or to the attachment currently being described, an attribute id, a length, the data, and a checksum. Walking it is straightforward; the interesting part is what the records contain.

Some hold plain values — the subject, the sent date, the sender’s display name. Others hold a serialised MAPI property blob: the same property model a .msg uses, flattened into bytes. That is where the real content lives, and it is why a TNEF reader ends up sharing most of its logic with a .msg reader despite the two formats having no structural resemblance at all.

Why the body is usually not HTML here either

The body follows the same order of preference as a .msg: PidTagHtml if present, otherwise de-encapsulated PidTagRtfCompressed, otherwise plain text.

And it is usually the RTF. That is not a coincidence — it is the whole reason the file exists. A winmail.dat is produced precisely when Outlook was sending in Rich Text format, so the message it carries is RTF almost by definition. A tool that extracts the attachments but shows you a plain-text body has skipped the de-encapsulation step, and you are seeing a degraded version of a message that is sitting right there in full. The same problem affects .msg files, where it is merely very common rather than close to universal.

Why the recipient list is genuinely gone

This is worth stating precisely, because tools that claim otherwise are guessing.

TNEF preserves the sender. It does not preserve To, Cc or the internet headers — not because the format lacks a place for them, but because of where the file sits. A winmail.dat is an attachment inside a carrying message. The recipients and the delivery path belong to that carrying message, and the attachment never had a copy.

So if you need to know who else received something, the answer is in the mail you received the winmail.dat with — open its headers there. Any viewer that displays a recipient list extracted from a winmail.dat is showing you something it invented.

Why the attachments still have their real names

One of the more useful details: TNEF stores an attachment’s name twice. There is a legacy 8.3-style title — INVOIC~1.PDF — and, in the MAPI property blob, PidTagAttachLongFilename holding the real one: Invoice 2026-03.pdf.

A reader that only looks at the legacy attribute gives you a folder of truncated uppercase names. Preferring the long name is the difference between recovering your documents and recovering something you then have to identify one by one. The MIME type is stored too, in PidTagAttachMimeTag, so files come back with the right type rather than one guessed from a mangled extension.

Inline images are marked with a content id, which is what lets them appear in the body rather than cluttering the attachment list — the same mechanism cid: references use in ordinary HTML mail.

A bug worth knowing about, if you are writing a reader

Strings in a TNEF property blob are stored NUL-terminated. The obvious way to strip that padding is to trim trailing zero bytes — and it is wrong for anything Unicode.

In UTF-16LE every Latin character has a 0x00 high byte. The word Whitfield ends 64 00, and with its terminator the tail of the buffer reads 64 00 00 00. Trimming byte-wise eats three zeros, leaves an odd number of bytes, and the final letter decodes as a replacement character. Every string loses its last character, quietly, in a way that reads as a rendering glitch rather than a decoding bug.

The fix is to trim in whole code units — two bytes at a time for UTF-16. It is a small thing, and it is the kind of small thing that only shows up when you test against something other than ASCII.

How the sender stops it happening again

Worth passing on, because it fixes the problem at source rather than one message at a time. In Outlook on Windows:

• For one message: in the compose window, open Format Text and choose HTML or Plain Text instead of Rich Text.
• For everything: File → Options → Mail, and under “Compose messages” set the format to HTML.
• For one stubborn contact: this is the usual culprit when it happens to the same person every time. Open the contact, double-click the email address, and set “Internet Format” to send plain text or HTML rather than Outlook Rich Text. A cached autocomplete entry can hold the old setting, so delete the address from the To field with the X in the dropdown before retyping it.

Related symptoms

The same message may also reach you as Part 1.2, ATT00001.dat or a nameless attachment — all of them are the same TNEF blob under a name some intermediate server invented, and all of them open the same way. If the file you have is an Outlook message rather than a TNEF blob, the won't-open troubleshooting guide covers that case, and what a .msg file is explains the format it is in.