Extract email attachments
Getting the files out of a batch of saved messages is a chore that mail clients are bad at: one message at a time, one attachment at a time, and no record afterwards of which file came from which message. When the messages are evidence — a claim, an audit, a discovery request — the record matters as much as the files.
This page reads .eml, .msg and .mbox, extracts every attachment stored by value, and writes them into a ZIP with a manifest.json recording, for each file, its SHA-256, its size and type, the message it came from, that message's subject, date and Message-ID, and whether the filename was taken from the message or generated here because the message did not supply one. Attachment names are reduced to a single safe path segment, so a message with a filename of "../../../etc/passwd" cannot write outside the archive.
The file is read by code running in this tab. It is not uploaded, not queued on a server and not seen by anyone but you — which also means there is no size limit imposed from outside, only what your own device can hold.
- 1.Drop message files, or a whole folder of them. Mailboxes are expanded and every message inside is included.
- 2.Extract. Every attachment is decoded, hashed locally with SHA-256 and placed in a folder named after its source message.
- 3.Download the ZIP. manifest.json beside the files records where each one came from.
Drop email files here
Built for .eml, .msg, .mbox. Nothing is uploaded — the file is read by code running in this tab.
What this page cannot do
- Attachments stored only as a reference — a link to a network path rather than the bytes — cannot be extracted, because they are genuinely not inside the file. They are listed in the manifest's failures section with that reason.
- Inline images referenced by Content-ID are extracted along with everything else and marked as inline in the manifest, because they are frequently the thing people actually want.
- Filenames are sanitised: directory separators removed, right-to-left override characters stripped, Windows reserved names prefixed, duplicates numbered. The manifest records the original where it differed.
- The whole ZIP is assembled in memory before it is offered, so a batch whose attachments total more than the tab can hold will fail rather than stream. The per-message export path avoids that.
If it did not work
- The ZIP contains only manifest.json.
- Why: None of the messages had attachments stored by value.
- Try: The manifest's failures list records this per message. Open a message in the viewer to see what it actually contains.
- Files are named image001.png, image002.png and so on.
- Why: Those are the names Outlook gives inline images, and they are the real filenames from the message.
- Try: The manifest ties each one to its source message, subject and date, so they can be told apart.
- Extraction fails on a very large batch.
- Why: The archive is built in memory.
- Try: Split the batch, or extract per message from the viewer.
Questions
Is my email actually uploaded anywhere?
No. There is no server here that accepts a file. The page's Content-Security-Policy sets connect-src to 'self', so the browser itself refuses any request to another origin, and form-action is 'none' so nothing can be submitted anywhere. The only network requests this site makes are for its own JavaScript, its own font files, and the Vercel page-view counter — which records that a page was viewed and nothing about what you opened. You can confirm all of it in your browser's network panel with the page open.
Does it work on a whole mailbox?
Yes. Drop an .mbox and every message in it is read and its attachments extracted, each into a folder named with the message's date and subject so the output is browsable. From the mailbox viewer you can also select a subset first.
Why are there SHA-256 hashes?
So the export is verifiable. The hash is computed by your browser from the exact attachment bytes; running shasum -a 256 on an extracted file gives the same value. That is what lets an extracted attachment be tied back to the message it came from later, and it is why the manifest records them alongside the source message's Message-ID.
Is a malicious attachment safe to extract here?
Extracting it is safe in the sense that nothing runs: attachment bytes are decoded, hashed and written into a ZIP, never executed or rendered. The extracted file is exactly as dangerous as it was inside the message, and the security panel flags executables, macro-enabled documents and double extensions before you download anything.
Related
- Open EML files — Open .eml email files in your browser with remote content blocked, full header analysis, attachment extraction and SHA-256 hashes. Nothing is uploaded.
- Open Outlook MSG files — Open .msg files from Outlook in your browser: body, HTML, recipients, dates, attachments and embedded messages, read from the real Compound File structure. Nothing is uploaded.
- Open and search MBOX mailboxes — Open large .mbox mailboxes in your browser: indexed locally, searchable by sender, subject and date, with per-message and batch export. Nothing is uploaded.