File formats

What Gets Lost When Email Changes Format

A run that moved everything and broke every attachment reports a perfect total. The count is the one thing that proves nothing.

Robert Smith 7 September 2026 6 min read

An email conversion loses whatever the destination format has no field for. Every conversion loses something and almost none of it is a fault in the software. A destination format either has a field for a thing or it does not. No amount of care creates one. Knowing which things have nowhere to go is the difference between a migration that surprises you and one that does not.

The message itself is rarely the problem. These formats all wrap the same object, so the body, its headers and the attachments travel well. What goes is everything layered on top of that by a particular program.

Four Layers And Only One Survives a Conversion

It helps to see a stored message as four things stacked rather than one.

The message Survives nearly everythingHeaders, body, attachments. Defined by a public specification that every format is built around
The container Usually survives, sometimes flattenedFolders, subfolders, the arrangement somebody built. A single message format has nowhere to put any of it
The application layer Rarely survivesCategories, flags, follow ups, voting responses. Added by one program and unknown to any other
The account layer Never survivesRules, signatures, autocomplete, permissions. Not in the mail file at all, so not what anybody is converting

Complaints after a migration almost always concern the third layer. The first two are usually fine and the fourth was never in scope, though nobody says so beforehand.

The fourth layer catches organisations out. Somebody converts a mailbox and checks the messages carefully. Weeks later they find that twenty years of rules and a signature block went nowhere. They were never in the file. They live in the profile. A mail file conversion has no relationship with them.

What Each Destination Format Cannot Hold

Rather than a matrix of every pair, the useful question is what a destination has no room for.

Converting to	What has nowhere to go
EML	Folder structure, plus the Outlook layer
MBOX	The Outlook layer. Folders become separate files
PST	Very little. It holds more than most sources
MSG	Very little per message. No folder structure either
PDF	Attachments as files, headers, threading, searchability as mail
CSV	Everything except the columns somebody chose

The pattern is worth naming. Moving between mail formats costs the application layer. Moving out of mail formats altogether costs the message.

Categories are the loss people notice months later. Somebody spent five years tagging correspondence by account. Every one of those labels lives in the Outlook layer and no other format has a field for it. Every message lands correctly and the filters built on those tags find nothing at all.

The Direction of the Conversion Decides Almost Everything

Conversions are not symmetrical. Which way you are going predicts the outcome better than which tool you use.

Toward a richer format

Nothing to lose

EML  -> PST
MBOX -> PST
EML  -> MSG

every field has
  somewhere to go

Anything the source could express, the destination can too. Nothing is left over.

Toward a simpler one

Something is left over

PST -> EML
MSG -> EML
PST -> MBOX

the message arrives
  the added layer
  does not

Not damage. There is simply no field in the destination for what is being dropped.

This is also why converting in a circle restores nothing. What the first move dropped was never written down, so there is nothing waiting on the way back.

Losing the application layer is often the right trade. It buys a format that everything can read and that will still open in twenty years. The point is making that trade knowingly rather than discovering it later.

What Goes Wrong Beyond the Format Itself

Format limits are predictable. These are the ones that catch people because they depend on the tool and the source rather than on the specification.

What happens	Why
Dates shift by an hour	An offset was dropped rather than carried
Accented names arrive as symbols	A charset declaration was ignored
Some messages have no attachments	A boundary stopped matching, often a line ending change
Filenames are truncated	Long paths, on Windows especially
Duplicates appear	A run was restarted rather than resumed
Very large messages are missing	A size limit somewhere, usually silent

Every row here is silent. None produces an error and all six report success. That is the argument for checking specific things afterwards rather than reading the summary the tool gives you.

What to Check When a Conversion Finishes

Not the count. A run that moved everything and broke every attachment reports a perfect total. The number is the one thing that proves nothing.
The largest message. Size limits are silent and they hit the biggest items first. Sort by size and open the top one.
The oldest message. Old mail was written by software nobody supports and it is where odd encodings and missing offsets live.
One with several attachments. Open them. Not the names in a list, the files themselves.
A message from before and after a clock change. Both correct means the offset is being carried. One wrong means every date in that half is out.
The folder tree. Count the folders, not the messages. Flattening is easy to miss when the total is right.

Six checks, about ten minutes. They find nearly everything that goes wrong in this area, while the source still exists rather than after somebody deleted it.

Two of the six checks above can be done before a conversion rather than after it, by opening the source and looking at the oldest and largest messages first. Our file viewers will show you what a source holds before anything moves. The converter pages each list what their particular route carries and what it drops.

Field level behaviour checked against RFC 5322 and the Microsoft MS-OXMSG specification in August 2026. Individual tools differ, so treat this as what the formats allow rather than what any one product does.

Questions People Ask

7 questions, answered in full below.

Does converting email lose anything?

It loses whatever the destination has no field for. The message itself almost always survives, since all these formats wrap the same object. What goes is the layer a particular application added on top of it.

Which conversions are lossless?

Moving to a format that holds more than the source. Everything in an EML fits inside a PST or an MSG, so those directions lose nothing. The reverse direction has fields with nowhere to go.

Why did my folder structure disappear?

Because single message formats have no concept of folders. Converting a mailbox to EML gives you messages. The folders become directories at best, which depends on the tool rather than the format.

Do attachments survive?

Between mail formats, yes. Into a document or a spreadsheet, no. A PDF of a message keeps the filenames and not the files, which surprises people who assumed a printed archive held everything.

What should I check afterwards?

Not the count. Check the largest message, the oldest one, something carrying several attachments and a pair spanning a clock change. Those four find nearly everything a count would miss.

Can I convert back afterwards?

Only to recover what survived. The dropped fields were never written into the new file, so a round trip returns you to less than you started with rather than to where you began.

Does better software avoid the loss?

Not the structural part. Where a destination format has no field for something, nothing can write it there. Software differs in how well it handles what is possible and not in whether the impossible becomes possible.

Sources

Where the figures and behaviour described above were checked.

Data conversion Wikipedia
Internet Message Format IETF, RFC 5322
MS-OXMSG, Outlook Item (.msg) File Format Microsoft Open Specifications