Regex Cheat Sheet for Email, Phone and URL Matching

Which regex should I use for email addresses?

The loose pattern ^[^\s@]+@[^\s@]+\.[^\s@]+$ accepts anything with no spaces, one @ and a dot after it. It is a good default for sign-up forms, because it rarely rejects a real address. The trade-off is that it allows some invalid ones; when searching text with the g flag and no anchors, it also picks up trailing punctuation, matching "sales@tools-star.co.uk," with the comma.

For extracting addresses from text, [A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,} is tidier: in our sample it found ali@example.com and sales@tools-star.co.uk and skipped "bad@" and "@x.com". The HTML standard defines a stricter pattern for type=email inputs, shown in the table below, which also accepts single-label domains such as ali@localhost.

Which regex should I use for phone numbers?

Phone formats vary so much by country that the most reliable approach is to store numbers in E.164 form: a plus sign, a country code and up to 15 digits in total. ^\+[1-9]\d{1,14}$ matches +971501234567 and +15551234567 and rejects 00971501234567 and +0123.

For North American numbers typed in different styles, \(?\d{3}\)?[\s.-]?\d{3}[\s.-]?\d{4} matches 555-123-4567 and (555) 987 6543. It will not match a UK number such as 07700 900123, which is a good reminder to test with numbers from every country your users come from.

Which regex should I use for URLs?

To validate a single link, ^https?:\/\/[^\s/$.?#].[^\s]*$ with the i flag requires http or https, then a host and no spaces. It accepted https://www.toolstarhub.com and rejected ftp://a.com and "https:// a.com". It also rejects a one-letter host such as http://x, because it expects at least two characters after the scheme.

To find links in text, https?:\/\/[^\s]+ is simple but swallows trailing full stops: it matched "http://example.org/path." with the dot. Ending the pattern with [^\s.,], as in https?:\/\/[^\s/$.?#].[^\s]*[^\s.,], trims it to http://example.org/path. For anything beyond a quick check, parse the link with the URL Parser, which breaks it into protocol, host, path and query.

How do I capture parts of a match?

Named groups make results easier to read. (?<user>[^\s@]+)@(?<domain>[^\s@]+\.[a-z]{2,}) applied to ali@example.com gives user = ali and domain = example.com, and the Regex Tester lists each named group beside the match.

Unnamed groups work too: they appear as group 1, group 2 and so on. Use (?: … ) for grouping you do not need to capture, as the HTML email pattern does, to keep the results clean.

Which flags matter for these patterns?

Without the g flag the tester returns only the first match; add g to list every email or link in a block of text. The i flag makes letters case-insensitive: ^[a-z]+$ fails on ABC without it and matches with it.

The m flag changes ^ and $ to match at each line. With a list of addresses on separate lines, ^\w+@\w+\.com$ found 0 matches with g alone and 2 with g and m. The s flag lets . match line breaks, and u enables full Unicode handling.

Which other patterns are worth keeping?

A few more patterns come up often in forms and data clean-up. US ZIP codes match ^\d{5}(-\d{4})?$, which accepts 12345 and 12345-6789 and rejects 1234. A whole-line match for digits only is ^\d+$, and \s{2,} finds runs of two or more spaces that you might want to collapse.

For dates written as YYYY-MM-DD, ^\d{4}-\d{2}-\d{2}$ checks the shape but not whether the date exists, so 2026-02-30 still passes. Check real dates with date code or a calendar tool after the pattern accepts the format.

When should I avoid regex?

Regex is good at shape checks but poor at structure. Parsing full URLs, HTML or JSON with a single pattern quickly becomes unreadable and fragile. Use a dedicated parser, such as the URL constructor in JavaScript, which the URL Parser relies on to split a link into parts.

For emails and phone numbers, the strongest check is to send a message or code and see whether the person receives it. Keep the regex loose enough not to block real users, and let the confirmation step do the real validation.

How do I debug a pattern that does not match?

Shorten the pattern until it matches, then add pieces back one at a time. In the Regex Tester, watch the match list change after each edit; the first piece that makes the matches disappear is the one to fix.

Check escaping next. A dot without a backslash matches any character, and a plus sign or brackets without escaping change the meaning. Finally, review the flags: a missing g shows only one match, a missing m stops ^ and $ from working per line, and a missing i makes capital letters fail.

How do I test a pattern before using it?

1. Collect samples. Write lines that should match and lines that should not, including edge cases from real data.
2. Paste pattern and text. Enter the pattern without slashes in the Regex Tester, up to 300 characters, and the text, up to 100,000 characters.
3. Pick flags. Use g to list all matches, m for line-by-line anchors and i for case-insensitive matching.
4. Check every result. Confirm each match and each miss. Adjust the pattern and retest until both lists are right.

Example

What should I keep in mind?

FAQ

Is there a perfect regex for email addresses?

No. Real address rules are complex and a pattern cannot tell whether a mailbox exists, so use a reasonable check and a confirmation email.

Which email pattern do browsers use?

The HTML standard defines the valid email address rule for input type=email, and the long pattern in this guide follows it.

Should I allow plus signs in emails?

Yes. Addresses such as first.last+tag@example.com are valid and common, and the patterns here accept them.

What is E.164?

It is the international telephone numbering format: a plus sign, a country code and the subscriber number, with up to 15 digits.

How do I match phone numbers with spaces or dashes?

Allow an optional separator between groups with [\s.-]? as in the North American pattern above.

Why does my URL regex include the full stop at the end of a sentence?

Because [^\s]+ matches every non-space character. End the pattern with a class that excludes punctuation, such as [^\s.,].

Do I need to escape slashes in the tester?

Escaping / as \/ is harmless and keeps the pattern portable to code that uses /…/ literals; the tester takes the pattern without surrounding slashes.

How do I make a pattern case-insensitive?

Add the i flag rather than writing both [A-Za-z] cases.

Why does ^ and $ only match once in my multi-line text?

Without the m flag they match the start and end of the whole text. Add m to match each line.

Can I use lookbehind in the Regex Tester?

The tester uses your browser's JavaScript regex engine, so lookbehind works in current browsers that support it.

Should I validate email only with regex on the server?

Use regex as a first pass, then send a confirmation message—RFC-complete email regex is impractical.

How do I allow optional country codes in phones?

Make the +country segment optional and constrain digit lengths per your market’s rules.

Why do URL patterns accidentally match markdown links?

Trailing punctuation and parentheses confuse naive patterns—trim common wrappers after the match.

Can I ban disposable email domains with regex alone?

Regex cannot keep up with domain lists; maintain an allow/deny list separately.

What flags help multiline phone lists?

Use multiline mode with ^ and $ per line, or split lines before testing each number.

How do internationalized domain names affect URL regex?

IDNs may appear as punycode; decide whether to allow Unicode host labels explicitly.

Is \d safe for phone digits in all locales?

\d may match more than ASCII 0–9 in Unicode modes—use [0-9] when you need ASCII only.

Should capture groups extract the TLD from URLs?

You can, but maintaining TLD lists is brittle; prefer a real URL parser when available.

How do I test patterns without pasting production data?

Use synthetic examples that cover edge cases—plus addresses, extensions, and long query strings.

Can possessive quantifiers speed up email checks?

They can reduce backtracking in some engines, but clarity and tests matter more than micro-tweaks.

Sources and further reading

• MDN – Regular expressions guide
• HTML Standard – The input element (valid email address)