Convert EML to PDF and keep the attachments intact
Most email-to-PDF tools do one of two unhelpful things with attachments: they drop them entirely, or they render them into the back of the body PDF. Both break the file as evidence. The first loses it; the second changes it.
EML Exhibit extracts every attachment byte-for-byte as its original file into a folder beside the message PDF. Attachments are never rendered into the PDF, never re-encoded, and never watermarked, so their hash values are identical to the versions that were sent.
The attachment is usually the evidence
The email is often just the delivery mechanism. The termination letter, the signed change order, the spreadsheet with the numbers that do not add up — the thing the case turns on arrives as an attachment, and the message body says “see attached.”
That makes attachment handling the part of email conversion worth being fussy about. A converter that quietly discards attachments produces exhibits that look complete and are not. A converter that renders them into the body PDF produces exhibits that look complete, are not verifiable, and have destroyed the native file’s live content along the way.
What byte-for-byte actually means
When a .eml file is parsed, attachments come out of the MIME structure
base64-decoded back into their original bytes. Writing those bytes to disk
without touching them means:
- The file’s hash — MD5, SHA-1, SHA-256, whatever your protocol specifies — is identical to the hash of the attachment as it sat inside the email.
- The file’s internal metadata is unchanged: authorship, creation date, application version, tracked changes, formulas.
- The file opens in its native application exactly as the recipient’s copy did.
That is the property that makes an extracted attachment usable as a native production, and it is not recoverable after re-encoding. Once a spreadsheet has been imaged, the formulas are gone; you cannot un-flatten it.
What the output looks like
A batch produces one PDF per message and, for any message carrying attachments, a folder of those files. Filenames carry the prefix you set, so a production sorted by matter stays sorted.
The folder structure is the parent-child relationship expressed in the only
form a filesystem can express it. It is deliberately simple, and deliberately
not a load file — building the BEGATTACH / ENDATTACH fields a review
platform wants is a downstream step, and it needs the original .eml files as
its source for the metadata.
The retention point nobody enjoys
Keep the .eml originals. The PDF is the readable exhibit. The extracted
attachment is the verifiable native. The .eml is the only artifact that
proves the two belong together, carries the transport headers, and can be
re-converted if the production specification changes.
Converted output here is deleted ten minutes after download and no copy is retained anywhere, which means your document store is the only copy that exists. That is the point — but it does put the retention obligation squarely on your side. Save the ZIP the moment it lands.
How to do it in EML Exhibit
-
Convert the batch as normal
Drop the .eml files in and choose PDF. No separate setting is needed; attachment extraction always happens.
-
Open the ZIP and look at the structure
Each message produces a PDF of the body and, where the message carried attachments, a folder holding those files under their original names.
-
Hash the attachments if the matter warrants it
Because the bytes are unchanged, a hash taken from the extracted file matches a hash taken from the same attachment inside the original .eml. Recording those hashes is what lets you show the file was not altered in handling.
-
Decide what gets imaged
If the production protocol requires attachments to be imaged and stamped alongside the parent, run the extracted files through your imaging step separately. The unmodified originals are what you image from.
-
Keep the .eml originals with the output
The .eml file is the native that ties the attachment to the message that carried it. Retain it even after the PDF is produced.
Why not just render the attachments into the PDF?
Because that changes them. Rendering a Word document or a spreadsheet into a PDF page re-encodes the content, and the resulting file has a different hash from the original. If anyone later asks whether the attachment you produced is the attachment that was sent, a hash match is the clean answer and re-encoding throws it away. It also flattens live content — a spreadsheet’s formulas, a document’s tracked changes — that may itself be discoverable.
Does this preserve the parent-child relationship?
Structurally, yes: attachments are written into a folder tied to the
message they came from, so the association is visible in the output. What
it does not do is generate the parent-child fields a review platform
expects in a load file. If you are producing into
a platform, that mapping is built during the load-file step, from the
folder structure and the original .eml files.
What about attachments inside forwarded messages?
An attachment carried by a forwarded message is extracted the same way,
because it is still an attachment on the .eml you converted. An email
attached to another email as a .eml or .msg file is extracted as that
file — it is not recursively converted into its own PDF.
Are the attachments watermarked on the free tier?
No. The free-tier watermark applies to rendered body pages only. Attachments are copied out untouched on every plan, because a watermarked attachment would be a modified attachment.
What if I only want the body pages?
Delete the attachment folders from the ZIP. It is deliberately easier to discard files you did not want than to recover files a converter silently dropped.