Convert EML to PDF

EML to PDF means a reading copy, not a screenshot

Converting an EML email to PDF is useful when the destination is a case folder, a meeting packet, a printout, or a document system that does not understand MIME. The output here is a consistent reading copy: decoded message headers, one selected readable body, page numbers when requested, and a manifest describing the attachments. It is not a screenshot of Gmail, Outlook, or Apple Mail, because an EML file does not preserve any one client's window, font installation, column width, or theme.

That distinction also keeps the result testable. Before generation, the page reports which headers and body alternative will be included, how many attachments will be listed, and any MIME or character-set warnings. Afterward it opens the generated bytes again, confirms that they form a PDF, and reads the real page count. An independent browser check extracts the expected header and body markers during release verification. A failed runtime reopen blocks download instead of handing you an unchecked document.

Which email body reaches the PDF

When the message has a plain-text alternative, that is the default. If HTML is the useful version, Safe HTML text extracts readable words and structural breaks with a tokenizer. The original HTML is available for inspection in the EML viewer, but it is never rendered into these pages. That means CSS-dependent columns, branded backgrounds, animated elements, and client-specific spacing do not survive. It also means a sender cannot make your conversion run a script or form.

The conversion does not activate links or request images, stylesheets, fonts, video, or tracking URLs. Inline CID images remain attachments rather than page artwork. This is a security and privacy guarantee, not a promise of visual fidelity. If you need a designed PDF from HTML you authored and trust, use a purpose-built document workflow; email from an outside source should not control the browser rendering the converter.

What happens to attachments

Attachment contents are not embedded, appended, converted, or flattened into the PDF. A spreadsheet might have many sheets, an archive might contain a directory tree, and a nested message might contain more files; silently converting those objects would make the result look complete while changing its meaning. Instead, an attachment manifest records the safe display name, media type, and decoded size so the reading copy documents what accompanied the email without pretending to preserve every payload.

Use the viewer to download an individual attachment in its decoded original bytes. It also explains filename changes made for portability, distinguishes CID parts from ordinary files, and lets a nested message/rfc822 part be saved as another EML. Signed content is not labeled verified, and encrypted S/MIME is not decrypted. Those limits carry into the manifest instead of disappearing from the PDF receipt.

Headers are decoded, but missing history is not reconstructed

The document includes familiar visible fields when present: From, To, Cc, Bcc, Reply-To, Date, Subject, and Message-ID. Encoded words and folded header lines are decoded according to the message syntax. A missing field stays absent. This converter does not infer a sender from a body signature, turn a display name into an email address, or rewrite a date into a timezone the source never declared.

Charset and transfer-encoding decisions are shown before the button is enabled. Common MIME bodies use quoted-printable or base64, and older messages may name Windows-1252 or ISO-8859 charsets rather than UTF-8. A recoverable fallback is marked. If boundaries or encoded bytes are broken badly enough that the intended message would be ambiguous, the conversion stops rather than typesetting a guess.

This PDF is not PDF/A or forensic preservation

The generated file is meant to be read, printed, searched, and filed as an ordinary PDF. It is not certified PDF/A, a cryptographic record of the source, or a replacement for the original EML. Keep the source file when exact headers, transfer encodings, signatures, attachment bytes, or chain-of-custody matter. The PDF receipt names the selected body and included sections so a later reader can understand what the transformation did.

Going backwards is not a meaningful inverse. A PDF has pages, drawing commands, and perhaps text; it does not contain the original MIME tree, mailbox addresses, transfer encodings, or attachments merely because those facts were printed on a page. For ordinary prose that starts as a text file, the TXT to PDF converter offers document layouts without claiming email structure. For words recovered from an existing PDF, use PDF to text.

Local conversion without a mailbox connection

Reading and PDF generation happen in the current browser tab. The EML bytes, addresses, subject, body, attachment inventory, and generated PDF are not uploaded or persisted in a URL or browser storage. No email is sent, and the page cannot log in to an inbox, reply, or forward. Large files receive resource advice rather than an arbitrary rejection. Open the guide to local processing if you want to watch the network boundary while converting a real message.