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 something@something.something 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 ada@example.com. — the address is not ada@example.com. 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. If you would rather work out the boundary yourself, the regex tester reports where each match starts and ends, so an address that quietly swallowed the full stop after it is visible as a position rather than as a bounced message a week later.

One more that turns up constantly in exported data: a leading apostrophe. Rows out of a database dump look like VALUES (1,'ada@example.com'), and an apostrophe is a perfectly legal character inside an address — o'brien@example.com 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. logo@2x.png 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@server is 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 Ada@example.com and ada@example.com 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: ada+news@example.com may be exactly the address you meant, so it is kept unless you ask for it to be folded onto the base mailbox.

Extracting the domain half tells you which hosts an address list already uses. It does not say whether a new brand name can be registered. For that job, the domain name finder combines word positions and asks the registry for the selected domain endings rather than inferring availability from an email string.

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.

The same block of text usually carries two other things worth pulling out, and each needs a different judgement rather than a wider pattern. Numbers are the harder of the two, because a date, an invoice reference and a router address all match anything generous enough to catch a telephone — so the phone number extractor insists on a recognizable form and prints what it refused. Links have the opposite difficulty: finding one is trivial and knowing where it stops is not, which is why the URL extractor counts brackets instead of stripping them.

One common source is not textual and needs a stop on the way. A message saved out of Outlook, ending in .msg, is a binary container rather than a thread you can paste, so dropping it in here finds nothing. Open it in the MSG viewer first, copy the body it lays out, and bring that back to this box — the forwarded chains inside long threads are exactly where the useful addresses tend to be hiding.

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.