Email Extractor

Why this email extractor does not touch a server

Think about what people actually paste into a tool like this. A contact form export. A customer list. The sign-up sheet for an event. An email thread with twenty people on copy. In other words: other people's names and addresses, held by you, on their behalf.

Sending that to somebody else's server to have the addresses picked out is not a small convenience with a privacy footnote. It is a disclosure of personal data to a third party, and in the EU and UK it is one with no lawful basis behind it — you did not collect those addresses in order to share them with a free web utility. Several of the tools that rank for this search are run by companies whose entire business is email addresses, which makes the exchange rather more pointed.

Here the text never leaves the tab. There is no upload endpoint, so there is nothing to trust: open your browser's network panel, paste your list, and watch nothing happen. The guide on verifying local processing walks through it properly if you have not done it before.

The part everybody gets wrong is the punctuation

Finding [email protected] takes one line of code, which is why every tool in this category exists. Getting it right takes considerably more, and the single most common failure is the full stop at the end of a sentence.

Contact [email protected]. — the address is not[email protected]. with a dot on the end, but a naive pattern happily includes it, and you find out when a hundred messages bounce. The same applies to commas, semicolons, closing brackets, angle brackets and quotation marks, all of which routinely sit against an address in real text. They are trimmed. A hyphen inside the domain is not, because that one belongs.

One more that turns up constantly in exported data: a leading apostrophe. Rows out of a database dump look like VALUES (1,'[email protected]'), and an apostrophe is a perfectly legal character inside an address — o'[email protected] is real. So the apostrophe is stripped at the front and kept in the middle, and a list pulled from a dump comes out usable rather than subtly wrong.

Things that look like addresses and are not

Two show up in nearly every technical document. [email protected] in a stylesheet matches any pattern that expects letters, an at sign and a dot — but.png is a file extension, not a domain ending. And deploy@serveris a valid internal reference with no dot at all, which is never the thing anyone wanted out of a document.

Both are skipped, and both are listed underneath the results with the reason. That matters more than it sounds: a tool that silently drops things gives you no way to disagree with it, and if it is wrong about your data you will never know. Note also that the file-extension check is a short, hand-picked list rather than a sweep of everything that looks like a filename — .zip, .app,.dev and .mov are all real domain endings now, and a blunt rule would have thrown away genuine addresses.

Duplicates, aliases and the case question

Any real list has the same address in it many times over, so duplicates are merged and you are told how many went. Matching ignores case even when the display does not, because [email protected] and [email protected] in one document are one person — showing them as two contacts is reporting a typo as a relationship.

The display keeps the case it found, though, and that is deliberate. The domain half of an address genuinely is case-insensitive; the part before the at sign formally is not, even though nearly every mail server treats it as though it were. Lowercasing the whole thing is what every other tool does silently, so here it is a checkbox rather than an assumption. Plus-aliases work the same way: [email protected] may be exactly the address you meant, so it is kept unless you ask for it to be folded onto the base mailbox.

Addresses written to avoid being collected

Some are written as name (at) example (dot) com. That spelling exists for exactly one reason: the person does not want to be harvested by a script.

They are counted and reported, and they are not decoded. Reading them back is trivially easy and it would mean overriding a clear request from somebody who is not the person using this tool — and that is the line this whole thing sits on. Staying quiet about them would be a different failure, so the number is shown: if you genuinely need one, you can read it with your own eyes, which is what the person who wrote it that way expected.

What this will not do

It will not fetch a URL, crawl a site, read your inbox or install itself into your browser. A large part of what gets called an email extractor is address harvesting for messages nobody asked for, and that half is not built here and will not be.

It also will not tell you whether an address still works. That is list verification, a genuinely different job requiring a server that talks to mail servers — and it is what several of the free extractors in this category are quietly a front door for. This one reads what you paste, and stops there.

Formats it reads, including some you might not expect

Anything textual. A pasted email thread, a copied web page, a CSV export from a contact form, a JSON API response, a .sql dump straight out of a backup. There is no parsing step to choose because there does not need to be one: an address looks the same in all of them, and the surrounding punctuation is handled the same way. If you have a dump and want a whole table rather than just the addresses,SQL to CSV lists the tables and lets you pick columns.

Nothing is refused for its size. Work that grows with the input runs off the main thread, so a large export is read without the page seizing up while it happens.