Friday, November 6, 2026 · Asia/KarachiFree tools · No signup · Runs in your browser

Extract Emails Tool

Extract Emails finds every email address in a block of text and lists them one per line. It is useful for pulling contacts out of a signature block, a long CC list, a web page source or a CSV that has addresses buried in notes. The rule is a practical pattern rather than the full email standard, and this page explains exactly what it accepts, what it skips and how to clean the list afterwards.

How to use

  1. Paste the text that contains the addresses.
  2. Press the button to extract them.
  3. Read the output: one address per line, or "(none)" if nothing matched.
  4. Remove duplicates if the same person appears more than once.
  5. Check unusual results, such as addresses glued to surrounding text.
  6. Only email people who have agreed to hear from you.

Formula / how it works

The tool searches for this pattern, ignoring case:

[A-Z0-9._%+-]+ @ [A-Z0-9.-]+ \. [A-Z]{2,}

Broken down:

  • Local part (before the @): letters, digits, dots, underscores, percent, plus and hyphen. That covers ali.khan, first_last and plus-addressing such as sales+pk.
  • Domain: letters, digits, dots and hyphens, so subdomains like mail.shop.co.uk work.
  • Top-level domain (TLD): a final dot followed by at least two letters. .com, .pk, .uk and long TLDs such as .travel or .photography all match.

Trailing punctuation is handled. Because the TLD must be letters only, a full stop at the end of a sentence is not included: "sales+pk@shop.co.uk." yields sales+pk@shop.co.uk.

Angle brackets and display names. In "Name" <n@d.io>, the brackets and display name are ignored and only n@d.io is extracted. That makes it easy to clean addresses copied from an email client's To field.

What is skipped:

  • One-letter TLDs, such as a@b.c, which do not exist on the public internet.
  • Social handles like @handles with nothing before the @.
  • Obfuscated addresses such as "ali [at] example [dot] com". Replace the words with symbols first if you need them.
  • Unusual but valid forms from the RFC 5322 standard, such as quoted local parts ("john doe"@example.com) or IP-address domains. These are almost never used in practice.
  • Internationalised addresses with non-Latin letters (for example Urdu or Chinese characters in the local part or domain), because the character classes are ASCII.

Possible false positives. Text such as image@2x.png matches the pattern, because "png" looks like a TLD. File names with @ in them are rare, but scan the output if you pasted code or asset lists.

Duplicates and case. Each occurrence is listed in order, so a thread where someone appears ten times gives ten lines. Email domains are case-insensitive and most providers treat the local part that way too, so Ali@Example.com and ali@example.com are usually the same inbox. Lowercase the list, then remove duplicates, for a clean contact list.

Validation is not delivery. A well-formed address can still bounce. Confirming that a mailbox exists needs a verification service or a confirmed opt-in email.

Cleaning workflow for a contact list:

  1. Extract the addresses here.
  2. Convert the list to lowercase.
  3. Remove duplicate lines.
  4. Sort alphabetically to spot near-duplicates such as ali.khan@ and alikhan@.
  5. Remove role addresses (info@, noreply@) if you only want people.

Privacy and law. Extraction happens in your browser. Sending marketing email to extracted addresses without consent can breach anti-spam rules such as GDPR in the EU and the CAN-SPAM Act in the US; use the list for contacts who expect to hear from you.

Worked examples

Sentence with plus-addressing

Inputs: Contact ali.khan@example.com or sales+pk@shop.co.uk.

Paste the sentence and press the button. Both addresses match; the final full stop is not part of the TLD because the TLD must be letters, so it is left out.

Result: ali.khan@example.com sales+pk@shop.co.uk

The +pk tag is kept; it routes mail within the same inbox.

Display names and an invalid TLD

Inputs: a@b.c, x@y.travel, "Name" <n@d.io>

Paste and extract. a@b.c is skipped because .c has only one letter. x@y.travel matches the long TLD, and n@d.io is taken from inside the angle brackets.

Result: x@y.travel n@d.io

Display names are dropped.

No addresses present

Inputs: no emails here, just @handles

Paste and extract. "@handles" has nothing before the @ and no dot after it, so the pattern does not match.

Result: (none)

Social handles are not email addresses.

Use cases

  • Pulling addresses from a long email thread or CC list.
  • Cleaning a contact export with addresses mixed into notes.
  • Collecting support contacts from a vendor document.
  • Checking which addresses appear in a page source before publishing.
  • Building an invite list from a registration spreadsheet column.

Tips & limitations

  • Lowercase and remove duplicates for a clean list.
  • Replace [at] and [dot] before extracting obfuscated addresses.
  • Scan for file names like image@2x.png in code pastes.
  • Verify deliverability separately before a large send.
  • Respect consent rules before emailing extracted contacts.

FAQ

Why was a@b.c not extracted?

The pattern requires a top-level domain of at least two letters, and one-letter TLDs do not exist.

Does it remove duplicates?

No. Every occurrence is listed. Lowercase the list and remove duplicate lines afterwards.

Does it include the full stop at the end of a sentence?

No. The TLD must be letters only, so trailing punctuation is left out.

Can it find addresses written as name [at] domain [dot] com?

Not directly. Replace " [at] " with @ and " [dot] " with . first.

Does it check that the mailbox exists?

No. It only finds well-formed text. Use a verification service or a confirmation email for that.

Is my text uploaded anywhere?

No. The search runs in your browser.

Runs entirely in your browser; your text is not uploaded. Counts and scores are heuristics, so review the output before you publish it.