· 6 min read
To extract email addresses from text, paste the text into the free email extractor, click Process, and copy the list: every address it finds comes back one per line, in the order it first appears, with duplicates removed. It runs in your browser tab, so the text is never uploaded.
TL;DR: paste text, click Process, copy the list. Plus tags, dots and multi-level domains are matched, mailto: prefixes and trailing punctuation are dropped, and Name@Example.com and name@example.com count as one address. Nothing is sent to a server.
The real specification for an email address (RFC 5322) is more permissive than the pattern anyone writes from memory. This is how the tool handles the common cases.
| Case | What the extractor does |
|---|---|
| Plus tags, like name+filter@example.com | Matched in full |
| Subdomains, like user@mail.example.co.uk | Matched in full |
| Long top-level domains | Matched: any run of two or more letters after the last dot |
| Trailing punctuation, like an address ending a sentence | The full stop is not included in the address |
| mailto:name@example.com, or an address inside <angle brackets> or quotes | Returned as name@example.com, without the prefix or the brackets |
| Obfuscated, like name at example dot com | Not found: it has no at sign to match |
| Non-Latin characters in the address | Not matched: the pattern accepts Latin letters, digits and . _ % + - only |
| Quoted local parts, like "first last"@example.com | Not matched: the quotes and the space split it into pieces |
Yes. Addresses are compared case-insensitively, so Name@Example.com and name@example.com are one recipient. The first spelling that appears is the one kept. A plain string comparison would treat them as two, and a recipient list built that way ends up with silent duplicates.
No. A list of email addresses is personal data, so where the extraction happens matters. The extractor runs in the browser tab: paste, process and copy without the text leaving the device. You can confirm it by disconnecting from the internet after the page has loaded and using it anyway.
No. Finding a string shaped like an address is not the same as confirming a mailbox exists behind it. The only way to know whether an address is live is to send to it, which extraction cannot do. For how addresses are delivered, see RFC 5321 on rfc-editor.org.
Extracting addresses from a page you do not own, to contact people who never asked to be contacted, is what anti-spam law exists to prevent. The legitimate cases are your own data: recipients from a thread you are part of, a list recovered from a broken export, or an audit of where addresses appear in a document before you share it.
Sources: RFC 5322, Internet Message Format (https://www.rfc-editor.org/rfc/rfc5322) defines what an address may contain. RFC 5321, Simple Mail Transfer Protocol (https://www.rfc-editor.org/rfc/rfc5321) defines how mail is delivered.
Related: How to extract URLs from text and keep them clean
Paste the text into the email extractor, click Process and copy the list. It is free and runs in your browser, with one address per line and duplicates removed.
They are merged case-insensitively, so Name@Example.com and name@example.com collapse into one line, keeping the first spelling found.
No. It finds strings shaped like addresses; whether a mailbox actually answers is only knowable by sending to it.
No. That form is written for a human reader and has no at sign to match, so it will not be found automatically.
No. The extraction runs in your browser tab, which matters because a list of email addresses is personal data by definition.