An email address finder for plain text scans the characters in front of you, recognizes the practical shape of a common email address, and returns a clean list with duplicates removed. The Lizely Email Extractor performs that scan entirely in your current browser tab: nothing is uploaded, no mail server is queried, and no address is "verified" beyond the visible character pattern. You paste up to 500,000 characters of notes, exported rows, prose, or any other text block, choose whether results should keep their first-appearance order or be sorted A–Z, and the tool returns one email per line with separate counts for unique, duplicate, and rejected candidates. Deduplication treats letter case as insignificant because [email protected] and [email protected] point to the same mailbox, but the tool preserves the first spelling it actually saw rather than rewriting it. Everything the tool reports comes from the text area you filled in — the extractor only reads the characters already present and never connects to DNS, SMTP, or any external service.
What "Email Address Finder" Means for Pasted Text
When people search for an email address finder, they usually have a pile of text already in hand — a contact note, a CSV export, a paragraph copied from a colleague's signature, or the contents of a help-desk ticket. The job is not to discover new addresses on the open web; the job is to lift the addresses that are already visible, ignore everything that merely looks like one, and hand back a list that can be pasted into a spreadsheet or CRM. That is exactly the scope of this tool.
The extractor works only on the characters inside the text area. It does not crawl pages, follow links, fetch mail headers, or look anything up. If the address is not present in the text you pasted, the tool cannot find it. This makes it a practical cleanup utility rather than a discovery service — useful for cleaning ordinary contact lists, pulling addresses from notes, preparing a small import, or inspecting test data without ever leaving the browser.
The Practical ASCII Pattern Behind the Extractor
An email address finder needs to decide which character sequences count. Rather than promise every legal mailbox allowed across the email standards, the Email Extractor recognizes an intentionally narrow ASCII form that covers the overwhelming majority of real-world addresses. The local part — everything before the @ sign — may contain letters, digits, dots, underscores, percent signs, plus signs, and hyphens, and is limited to 64 ASCII characters. A dot cannot start or end the local part, and two dots cannot sit next to each other, which blocks frequent false positives like [email protected].
The domain part uses DNS-style labels separated by dots. Each label must contain letters, digits, or interior hyphens, and may not begin or end with a hyphen or be empty, mirroring the preferred name syntax described in RFC 1035 section 2.3.1. There must be at least two labels, and the final label must contain between 2 and 63 ASCII letters under this tool's practical policy. The full candidate, including the @ sign, is rejected if it exceeds 254 characters. These rules together exclude a long list of obviously malformed inputs without needing to be a full RFC 5322 parser, which matches the practical guidance in MDN's email input validation reference.
| Sample text | Result | Why |
|---|---|---|
| [email protected] | Accepted | Standard practical ASCII form |
| [email protected] | Accepted | Dots, plus, and subdomain all legal |
| [email protected] | Rejected | Consecutive dots in the local part |
| [email protected] | Rejected | Domain label starts with a hyphen |
| [email protected] | Rejected | Domain label ends with a hyphen |
| [email protected] | Rejected | Empty domain label |
| [email protected] | Rejected | Final label needs at least 2 letters |
| alice@example | Rejected | Single-label host, no dot in domain |
| mailto:[email protected] | Extracts [email protected] | mailto: prefix is intentionally allowed |
| https://[email protected]/private | Not extracted | URL userinfo handled conservatively |
| café@example.com | Rejected | Non-ASCII letter in the local part |
How to Extract Email Addresses From Pasted Text
- Paste the text containing possible email addresses into the text area and watch the visible counter; extraction fails without processing if the input exceeds 500,000 JavaScript characters.
- Decide whether you want the results in first-appearance order or sorted A–Z (case-insensitive). First-appearance order preserves the original sequence in which the addresses were encountered.
- Select Extract emails. The tool scans the text locally, runs the practical ASCII validator on each candidate, and deduplicates using a lowercase key while preserving the first spelling seen.
- Read the three counts reported below the result: unique addresses kept, duplicates removed, and candidates rejected for failing validation.
- Copy the result using the Copy all action, which uses the browser clipboard asynchronously and only reports success for the current run. If clipboard permission is unavailable, the output remains selectable so you can copy it manually.
- If you edit the input or change the sort order, the prior list, error, and copy status are cleared so an old result cannot remain on screen as if it matched the new text.
Working through a quick numeric example: paste a text block containing [email protected], [email protected], [email protected], [email protected], and a duplicated [email protected] later in the same paragraph. The run produces 2 unique results kept in the order encountered, with the first spelling preserved as [email protected] and [email protected]; 2 duplicates collapsed into existing keys; and 1 rejection for the consecutive-dot candidate. The arithmetic is unique 2 + duplicate 2 + rejected 1 = 5 total candidates, and every number is read straight from the counts the tool displays after the run.
What Gets Rejected and Why
The reject count exists so the transformation is auditable, not so the tool can claim to be picky. Common sentence punctuation acts as a natural boundary: commas, semicolons, closing brackets, quotes, and exclamation marks all stop the candidate scan. Trailing sentence periods or ellipses are removed before validation so that a sentence ending with "Email me at [email protected]." does not get rejected for the trailing period. If a malformed stretch is broad enough that the validator cannot be sure where the address begins or ends, the whole candidate is rejected rather than silently extracting a valid-looking suffix from it. Unicode text immediately attached to an address-shaped suffix is also rejected as one unsupported candidate instead of returning only its ASCII tail.
URLs are handled conservatively. A mailbox-shaped userinfo segment inside an HTTP, HTTPS, or FTP URL, such as https://[email protected]/private, is rejected rather than reported as a contact address, because most of those addresses are login names rather than mail destinations. A mailto: address remains extractable because its purpose is explicitly an email destination. If your pasted text is an exported Gmail or Outlook thread rather than a contact list, the guide on extracting emails from Gmail without uploading walks through a matching workflow in more detail.
Limits, Counts, and Error Behavior
The tool's limits are explicit so a quiet truncation cannot mislead you. The input text area accepts at most 500,000 JavaScript characters; instead of silently stopping at the boundary, the visible counter marks an over-limit value and extraction returns an error without processing the input. At most 1,000 unique addresses can be returned; if a text contains more, the operation fails with a message and does not expose a partial first thousand. The duplicate and rejected counts are shown only after a successful run so you can see exactly how the input was transformed.
| Constraint | Value | Behavior when exceeded |
|---|---|---|
| Input length | 500,000 characters | Counter flags over-limit; extraction errors without processing |
| Unique addresses | 1,000 | Explicit error, no partial list returned |
| Local-part length | 64 ASCII characters | Candidate rejected, counted |
| Total address length | 254 characters | Candidate rejected, counted |
| Final domain label | 2–63 ASCII letters | Candidate rejected, counted |
A failed extraction clears the old result before reporting the problem, so a list produced from earlier text cannot remain on screen as if it matched the current text. Editing the input or changing the sort order triggers the same reset, and an in-flight copy status update is invalidated if the page is left or the result changes.
What the Email Extractor Does Not Check
An email address finder that runs entirely on a pasted text block cannot answer the questions that matter before you actually send mail. The tool does not fetch links, inspect pages, follow redirects, query DNS, test SMTP servers, or send verification messages. An extracted string is not proof that a mailbox exists, that it accepts mail, or that the address belongs to the person you think it does. The extractor does not detect typographical domains, distinguish disposable mailboxes, identify role accounts, or check suppression lists.
Before any address leaves the tool, review consent, privacy rules, jurisdictional requirements, and the source of every line. For high-stakes account creation or deliverability work, combine appropriate confirmation, DNS checks, bounce handling, and human review rather than treating a pattern match as verification. Used for what it actually does — pulling practical ASCII addresses out of text you already have, deduplicating case variants, and handing back a clean newline list — it removes most of the mechanical friction of preparing a small contact import.
Related reading: Extract Numbers From Text Online With Rule Switches.