> Source: https://txtfetch.com/tools/email-to-text > Plain-text twin — every page on txtfetch.com has one. https://txtfetch.com/text --- # Your email, as text. Attachments included. Drop a real .eml or Outlook .msg below. Watch the headers, body, and every attachment's text come out right here, in your browser. Nothing is uploaded. It's the same read txtfetch's API gives you, just local. Drop a real .eml or Outlook .msg file below to see the headers, body, and attachment text it extracts to. Attachments are recursed through, too. It runs entirely in your browser, and nothing is uploaded. ## whats-hard-about-email An .eml is RFC-822 headers over a MIME body. The body is rarely just "the text." It's usually a tree of multipart/alternative and multipart/mixed parts, where the plain-text and HTML renditions of the SAME content sit side by side. Only one of them should end up in your output. Read both and the text doubles. Read the wrong one and you inherit HTML markup you now have to strip. Encoded-word headers (=?utf-8?Q?...?=) need their own decode step. So do per-part charsets and transfer encodings, like quoted-printable and base64, before any of that text is readable at all. Outlook's .msg is a completely different problem. It is not RFC-822 or MIME at all. It's an OLE2 compound-file container, the same binary-filesystem-in-a-file format as legacy .doc/.xls, holding MAPI property streams named things like \_\_substg1.0\_1000001F for the body. There's no header block and no boundary strings. A parser built for RFC-822 fails on a .msg outright, because it's looking for a structure that simply isn't there. This tool ships its own from-scratch OLE2/CFB reader, FAT, mini-FAT, and all, because there's no other way to get inside one in a browser. And here is the actual point of this page: attachments aren't opaque blobs. A Word document attached to an email is itself a document that needs extracting. A PDF attachment might be a scan with no text layer. A forwarded email shows up as a message nested inside a message. Most "email to text" tools stop at the body and hand you attachments as base64, or as filenames with no content. This one recurses into each attachment with the SAME in-browser extractors the other tools on this page use. A .msg with a Word attachment gets you the message text AND the attachment's text, in one drop. ## what-to-do-next Got the text out and want the API call for it directly? The panel above already has it, with your file's real name. Working with a whole .mbox archive, a .pst/.ost mailbox, or messages bigger than this browser tool's 25 MB cap? [See the full email extraction guide (.eml, .msg, .mbox) →](https://txtfetch.com/extract/email) covers .eml and .mbox end to end; [the .msg/.pst/.ost internals guide](https://txtfetch.com/extract/msg) covers Outlook's own container format specifically. ## faq **Does this tool upload my email anywhere?**: No. Everything happens in your browser. The .eml or .msg bytes are parsed locally with a hand-rolled MIME/OLE2 reader, and never sent over the network. Only the finished text ever leaves your machine, and only if you choose to copy or download it. That matters more here than for most file types, since real email is often the most sensitive thing anyone drops into a converter. **Does it handle Outlook .msg files, not just .eml?**: Yes. This tool includes its own from-scratch CFB/OLE2 reader. It walks a .msg file's MAPI property streams directly, including the mini-FAT, where most of a real .msg's small properties live. Subject, body, sender, recipients, and attachments all come from the same reader the API's Tika pipeline effectively mirrors. **Are attachments extracted, or just listed?**: Extracted, recursively. A Word, Excel, or PowerPoint attachment gets its actual text pulled out with the same in-browser extractor the /tools/docx-to-text page uses. A PDF attachment gets a text-layer verdict, not the text itself; see the FAQ below. An embedded .msg or .eml gets expanded the same way, up to three levels deep. **Does a PDF attachment's text get extracted too?**: No. For a PDF attachment, this browser tool only reports whether it HAS a text layer, the same structural check as /tools/pdf-text-check, not the text itself. Extracting PDF text is a heavier job than this quick client-side check does. txtfetch's API returns the actual text for a PDF attachment, in the same request. **What about images, scanned attachments, or a .msg's forwarded .doc file?**: Named honestly, not silently dropped or guessed at. Images are listed as images; OCR only happens server-side, never in your browser. A legacy .doc/.xls/.ppt attachment, a different binary format from .msg despite sharing the OLE2 container, is named as such rather than misread. Nothing here is dressed up as more than it is. **Does it work on a whole .mbox archive, or a .pst/.ost mailbox file?**: Not a multi-message archive. This tool reads one message at a time. An .mbox holding several messages, or a .pst/.ost, gets an honest message pointing at the right page. A .pst/.ost is a whole mailbox database. Either way, that's better than a guess at which message you meant. One exception is still a single message. A file saved by mutt, pine, or Unix mail carries a "From " envelope line in front of the message. That gets unwrapped and read normally. txtfetch's API handles full .mbox, .pst, and .ost archives directly. **Is there a file size limit?**: This tool reads up to 25 MB entirely in your browser. It has its own caps on attachment count, recursion depth, and total output. So a hostile or malformed file can't hang the tab. Larger messages, or a batch you want to automate, go through the same extraction via the API, which has no such limit. ## That was one file. The API does the queue. This page read your email on your own machine. The API reads a folder of them. [Read the quickstart →](https://txtfetch.com/docs) [Get an API key →](https://app.txtfetch.com/signup)