How to extract email addresses and links from text

Turn notes, logs or copied text into a list of matching addresses and links. Review duplicates, punctuation and the limits of pattern matching.

By ToolsNow · Published 31 July 2026

If a document contains addresses or links you need in a list, pattern matching can collect them without copying each one by hand. It can also capture incomplete or unwanted matches.

Use the text extractor to build the list, then review it. A matching email address is not proof that the mailbox exists, and a matching URL is not proof that the destination is safe.

Matching a shape isn’t verifying a thing

Every extraction tool, this one included, finds text that looks like a particular kind of value. That’s the whole of what it does. It can’t tell you:

whether an email address receives mail
whether a phone number connects to anyone
whether a URL resolves, or is safe
whether a number is a price, an ID, or a fragment of a date

What you get back is a list of candidates. Treating it as verified data is where things go wrong, most visibly when somebody extracts addresses from a document and mails all of them.

Emails: the RFC trap

The formal grammar for email addresses, RFC 5322, is notoriously permissive. It allows quoted local parts with spaces, comments in brackets, and nesting that no mail provider on earth actually accepts. The “correct” regular expression for it runs to thousands of characters, and it’s a well-known catastrophic-backtracking hazard on top of that: certain inputs make it run effectively forever.

The workable answer is to match the addresses people actually use. Letters, digits and a bit of punctuation, an @, then a domain with at least one dot. You’re trading theoretical completeness for a pattern that’s fast and predictable, and that’s the trade the extraction tool makes.

Watch for these false positives:

Version strings and handles. user@2x, or a Twitter-style @name sitting next to a word, can form something address-shaped.
Trailing punctuation. In “email me at [email protected].” the full stop is sentence punctuation, not part of the domain, and a naive pattern keeps it.
Concatenated text from a badly converted PDF, which can fuse two addresses into one.

URLs: where does the link end?

The hard part of URL extraction is knowing where to stop. A URL can legitimately contain brackets, commas and full stops, and sentences also end with those characters. Look at this:

See https://example.com/docs/(v2), or https://example.org/a.

The first URL really does contain brackets. The second ends before the full stop. No pattern gets this universally right. The workable heuristic is to strip trailing sentence punctuation and balance brackets, keeping a closing bracket only when there’s an opening one to match it.

Bare www. hosts are worth catching too, since plenty of text drops the scheme. Be careful what you do next, though: a URL pulled out of an untrusted document should never be rendered as a live link by default. Reading the destination first is the entire point.

Why phone numbers need a closer check

There’s no universal phone-number format. The ITU standard, E.164, caps numbers at 15 digits; national formats start at 7 and go up; and grouping conventions differ wildly, with spaces, dots, hyphens and brackets all optional.

So any pattern broad enough to catch real numbers internationally will also catch order and invoice references, dates written as long digit runs, ID and account numbers, and product codes.

The honest approach is to accept the 7–15 digit range, say plainly that some matches won’t be phone numbers, and let you filter. A tool that claims to “validate” phone numbers pulled from free text is claiming something it can’t do without a country context and a numbering-plan database.

If your data has a consistent format, one country or a known prefix, a custom pattern will beat any general one. That’s what the custom regex field is for.

Handling duplicates

Deduplication looks simple until you hit case. [email protected] and [email protected] almost certainly reach the same mailbox: the domain is case-insensitive by specification, and effectively every provider treats the local part that way too. Folding case is usually right for email and domains.

It’s usually wrong for identifiers. SKU-a1 and SKU-A1 might well be different products. Which is why case-insensitive comparison is a separate toggle instead of an assumption.

Keeping a count next to each unique value beats a plain unique list. It tells you which address runs through the whole thread and which one turned up once in a signature.

Regex, briefly

A handful of pieces covers most extraction work:

\d a digit, \w a word character, \s whitespace
+ one or more, * zero or more, ? optional
{3} exactly three, {2,4} two to four
[A-Z] a character set, [^,] anything but a comma
\b a word boundary, which is the fix for matching “cat” inside “category”
() a group you can refer back to

Two habits prevent most of the pain. Anchor with \b wherever a match shouldn’t start mid-word. And don’t nest quantifiers: patterns like (a+)+b are the classic recipe for catastrophic backtracking, where a non-matching input takes exponentially long. If a pattern hangs the page, that’s almost always why.

Privacy, which matters more here than usual

What people feed this kind of tool is very often a customer list, a support thread or a server log. Those are exactly the things that shouldn’t be pasted into an unknown website, because the tool sees the whole document and not just the matches.

The extraction tool here runs entirely in the page, so nothing you paste gets uploaded. Check that on any tool you use for this sort of data: open the network tab and confirm nothing leaves.

And once you have the list, the ordinary obligations still apply. An address appearing in a document somebody sent you is not consent to market to it.

Sources and further reading

Last reviewed 31 July 2026.