The job that made me build this arrived as a forwarded email chain forty messages deep. A client wanted a single list of everyone who had been copied on a six-month thread so they could migrate the group to a proper mailing list. Every address was in there, buried in To: and Cc: lines, in signatures, in quoted replies, sometimes three times over. Scrolling and copying by hand was going to take an afternoon and I would still miss a few and duplicate a few more. What I actually needed was something that would read the whole blob of text, find every email address in it, throw away the duplicates, and hand me a clean list. That is the email extractor, and this guide explains how it works and why the boring details of the matching matter.
TL;DR: An email extractor scans a block of text and pulls out every email address it contains, returning a de-duplicated list you can copy. The Toolz tool goes further, extracting URLs, phone numbers, and IPv4 addresses from the same text with the same engine. It matches with curated regular expressions, collapses duplicates case-insensitively, and can sort and lowercase the output. Everything runs client-side: no upload, no signup, works offline.
I build SaaS products on Laravel and React and I ship WordPress plugins, and a surprising amount of that work is turning unstructured text into structured lists. A support inbox export, a scraped page, a log file, a pasted document: they all mix the data you want with noise around it. Pulling the addresses, links, or IPs out of that noise is a small task you do constantly, and doing it with a regular expression you half-remember and retype every time is exactly the friction a browser tool should remove. So this is the guide I wish I had the afternoon that forty-message chain landed in my lap.
What is an email extractor?
An email extractor is a tool that reads free text and returns every email address inside it as a list. You paste a block of text, whether that is an email thread, a web page, a CSV dump, a chat log, or a page of source code, and the tool finds each address using a pattern that recognizes the shape of an email: a local part, an at sign, and a domain ending in a valid top-level domain. Instead of reading the text yourself and copying addresses one at a time, you get the whole set at once, with duplicates removed.
The Toolz email extractor is deliberately more than emails. The same scanning engine can extract http and https URLs, phone numbers, and IPv4 addresses, because they are the same class of problem: find every occurrence of a known pattern in a wall of text and list it cleanly. That makes it a general extraction utility rather than a single-trick tool. The core idea is constant across all four types. Define a precise pattern for what a valid match looks like, scan the text for every non-overlapping occurrence, then clean, de-duplicate, and optionally sort the results into a list you can paste wherever you need it.
Why not just eyeball it or use find-in-page?
Because both methods fail in the ways that matter most. Reading text and copying addresses by hand is slow, and worse, it is unreliable: you miss the address tucked inside a signature block, you copy the same one twice from a quoted reply, and you have no way to know how many you should have ended up with. The larger the input, the worse the odds, and the inputs that need extracting are usually the large ones.
Browser find-in-page is no better for this. It highlights matches for a string you already know, but the whole point of extraction is that you do not know the addresses in advance, so there is nothing to search for. What you need is a pattern that matches the shape of an email regardless of its exact letters, which is precisely what a regular expression provides. Writing that expression correctly is its own small skill, and getting it slightly wrong means either missing valid addresses or catching junk that only looks like one. A dedicated extractor bakes a tested pattern in so you never have to retype it, and pairs it with de-duplication so the list you copy is the list you can trust. If you want to understand or adjust the pattern itself, the regex tester lets you paste your own expression and watch it match against sample text in real time.
How accurate is the email matching?
This is the question that decides whether an extractor is useful or annoying, so it is worth being precise. The email address format is defined by RFC 5322, and the full grammar is famously baroque. It permits quoted local parts with spaces, comments in parentheses, and other forms that are technically valid and never once appear in real data. A regular expression that tries to match the entire RFC is enormous, and in practice it does more harm than good, because it starts matching strings that no mail server would ever accept.
The Toolz extractor uses the pragmatic subset that the industry has settled on: a local part of letters, digits, and the common punctuation, an at sign, and a dotted domain that ends in a top-level domain of at least two letters. This is the same shape most validation libraries use, and it matches the addresses people actually have while rejecting the noise. It is a deliberate trade. You give up matching the exotic forms that do not occur in order to avoid false positives on the forms that look like emails but are not. For pulling addresses out of real documents, which is the whole job, that trade is the right one. The tool is honest about it too: the same reasoning applies to phone numbers, where there is no single global format, so the pattern is intentionally broad and occasionally catches a long number that is not a phone number, which is why reviewing phone results is worth a moment.
How do I extract emails from text with the tool?
The flow takes about ten seconds. Paste your text into the input box, or click Load Sample to see a worked example that contains emails, URLs, phone numbers, and IP addresses all mixed together.
Choose what to extract using the row of buttons at the top: email addresses, URLs, phone numbers, IPv4 addresses, or numbers. The tool applies the matching pattern for that type and ignores everything else. Then set the list options. Leave "Remove duplicates" on to collapse repeated matches into a single entry, which is almost always what you want. Turn on "Sort" to order the list alphabetically, or by value when you are extracting numbers. Turn on "Lowercase" to normalize emails and URLs so [email protected] and [email protected] are treated as one address. Pick how the results are joined: new line for a vertical list, comma for a CSV cell or a To: field, space, or semicolon for the mail clients that expect it.
Click Extract and the results appear with a count of how many matches were found and how many duplicates were removed. Copy the list and paste it wherever it needs to go. That is the entire loop, and because it runs instantly you can flip between extraction types on the same text to pull emails, then URLs, then IPs, without re-pasting anything.
What can I extract, and when would I use each?
The four extraction types cover the data that most often hides inside text. Here is what each one matches and the situation it is for.
| Type | Matches | Typical use |
|---|---|---|
| Email addresses | [email protected] in the practical RFC subset |
Building a mailing list from a thread, pulling contacts from an export |
| URLs | http:// and https:// links, trailing punctuation trimmed |
Collecting every link from a page or document for auditing |
| Phone numbers | Runs of 7+ digits with spaces, dashes, dots, or parentheses | Gathering contact numbers from scraped or pasted text |
| IPv4 addresses | Dotted quads with each octet bounded to 0-255 | Pulling addresses out of a log file or a config dump |
| Numbers | Signed integers and decimals, with thousands separators | Extracting figures from a report or a table pasted as text |
The email and URL types are the ones I reach for most, usually together: extract the emails to build a contact list, then switch to URLs to audit every link the same document references. The IPv4 type earns its place when I am reading server logs and want the unique set of addresses that hit an endpoint, which pairs naturally with the URL parser when I then need to break those requests down further. The number type is the odd one out but genuinely handy for lifting figures out of a report that was pasted as plain text instead of a spreadsheet. Whichever you pick, the de-duplication and sorting options work the same way, so the output is always a clean, ordered list rather than raw matches.
How does de-duplication actually work here?
De-duplication sounds trivial until you consider casing. The same person's address can appear as [email protected] in one signature and [email protected] in a quoted reply, and a naive de-duplicate that compares strings exactly would keep both. That is wrong: email local parts are case-insensitive in every practical mail system, and domains are case-insensitive by definition. So the extractor compares emails and URLs case-insensitively when deciding whether two matches are the same, which means those two spellings collapse to one entry even if you have not turned on the lowercase option.
The tool also tells you what it did. The count above the results shows both how many matches it found in total and how many duplicates it removed, so you are never guessing whether the list shrank because of de-duplication or because the input was smaller than you thought. For numbers and IP addresses, where casing is irrelevant, the comparison is exact. This is the kind of detail that is invisible when it works and infuriating when it does not, which is why it is worth getting right rather than leaving to a plain Set of raw strings. If your job is really about which values appear in one list but not another rather than pulling them out of prose, the compare two lists tool does set arithmetic on columns and is the better fit for that specific question.
Is it safe to extract from sensitive text online?
For this tool, yes, and the reason is how it is built rather than a policy you have to take on faith. The text you paste is scanned entirely in your own browser with JavaScript. There is no upload, no server round trip, and nothing is logged or stored. You can confirm it by opening your browser's network tab and clicking Extract: no request leaves the page. Once the page has loaded you can go offline and it keeps working.
This matters more for extraction than for almost any other kind of tool, because the text you paste is frequently full of exactly the data you would not want to leak. Email threads contain private addresses, log files contain internal IP addresses and hostnames, and pasted documents contain phone numbers and names. An extractor that uploads that text to a server to process it, however well intentioned, turns your private correspondence into someone else's server log. Client-side processing removes the risk at the root: the text never leaves your machine. That default is deliberate across every tool on toolz.dev, and I laid out the full argument in the data privacy guide for online tools if you want the reasoning in depth. For a wider look at how these small utilities fit together into a working kit, my developer productivity tools guide walks through the pieces.
What are the limits worth knowing?
Being straight about limits is part of trusting a tool, so here are the honest edges. The email pattern matches the practical subset of RFC 5322, not the full grammar, so a technically valid but exotic address with a quoted local part or a comment will be missed. That is a deliberate choice to avoid false positives, and it affects essentially no real address, but it is a limit and you should know it exists. Phone numbers are the loosest of the five types, because there is no universal format; the pattern looks for a run of seven or more digits with common separators, which means it can occasionally catch a long identifier that is not a phone number, so a glance at the phone results is worth the second it takes.
The extractor also works on text, not on binary files. If you have a PDF or a Word document, copy its text and paste that; the tool cannot read the file format itself. And because everything runs in browser memory, a genuinely enormous input will be limited by your browser rather than by the tool, though for the emails, links, and IPs people actually extract that ceiling is far above what you will hit. None of these limits bite in normal use. Knowing them is just the difference between using the tool with confidence and being surprised by an edge case.
Frequently asked questions
How do I extract email addresses from text? Paste the text into the email extractor and leave the type set to email addresses. It scans the text with an email pattern, lists every address it finds, removes duplicates, and lets you copy the clean list. No signup or upload is needed, and it works offline once loaded.
Can it extract URLs and phone numbers too? Yes. Switch the extraction type to URLs, phone numbers, IPv4 addresses, or numbers. The same engine applies a different pattern for each type, so one tool handles several extraction jobs from the same block of text without re-pasting it.
Does it remove duplicate emails? Yes, when the remove-duplicates option is on. Repeated matches collapse to a single entry, and the tool reports how many duplicates were removed. Emails and URLs are matched case-insensitively, so the same address in different letter casing is treated as one.
How accurate is the email matching? The pattern matches the practical subset of email addresses seen in real data: a local part, an at sign, and a dotted domain ending in a valid top-level domain. It does not implement the full RFC 5322 grammar, which allows exotic forms that never appear in practice and would produce false matches on strings that only look like emails.
Why are some phone numbers matched oddly? Phone numbers have no single global format, so the pattern looks for a run of seven or more digits with spaces, dashes, dots, or parentheses between them. This is deliberately broad, which means it can occasionally catch a long number that is not a phone number, so it is worth reviewing the results when extracting phone numbers from mixed text.
Can I sort the extracted list? Yes. Turn on the sort option to order the list alphabetically, or by numeric value when extracting numbers. Combine it with the remove-duplicates option to get a clean, ordered, duplicate-free list ready to copy.
What formats can I copy the results in? You can join the matches with a new line, comma, space, or semicolon. Choose new line for a vertical list, comma for a CSV cell or a To field, and semicolon for some mail clients. The count above the output shows how many matches were extracted.
Is the extracted data uploaded anywhere? No. The text is scanned locally in your browser with JavaScript. Nothing is transmitted, logged, or stored, and the tool keeps working offline once loaded, which you can confirm by watching the network tab while you extract.
