Common Regex Patterns for Email, Phone, URL Validation
Certain validation tasks come up in almost every web project: checking that an email address looks plausible, confirming a phone number contains the right number of digits, verifying that a URL uses an accepted scheme. Regular expressions are the standard tool for all of these, but writing them from scratch each time is unnecessary — a handful of well-tested patterns cover the vast majority of use cases. This article presents production-ready patterns for email, phone, and URL validation, explains the logic behind each, and shows you how to test and customize them in the WikiPlus Regex Tester.
Email Validation Regex Patterns
Email addresses follow the format local-part@domain. The local part can contain letters, digits, and several special characters including dots, plus signs, hyphens, and underscores. The domain consists of labels separated by dots, ending in a TLD of two or more letters. A practical pattern for most web applications: ^[\w.+-]+@[\w-]+\.[a-zA-Z]{2,}$ Breaking it down: ^[\w.+-]+ — the local part starts at the string beginning (^) and contains one or more word characters, dots, plus signs, or hyphens. @ — the literal @ separator. [\w-]+ — the domain label: word characters and hyphens. \. — a literal dot. [a-zA-Z]{2,}$ — the TLD: two or more letters, ending the string. This pattern accepts addresses like user@example.com and user.name+tag@sub.domain.co without being overly strict. It rejects strings without @, without a dot in the domain, or with a TLD shorter than two characters. For stricter validation that allows subdomains: ^[\w.+-]+@[\w-]+(\.[\w-]+)*\.[a-zA-Z]{2,}$ Important caveat: email validation via regex should be a first-pass sanity check, not a guarantee of deliverability. The only reliable way to confirm an email address exists is to send a confirmation email. Use regex to reject obviously malformed input, not as a definitive validator. Test both patterns in the WikiPlus Regex Tester against a mix of valid addresses (user@domain.com, first.last@company.org) and invalid ones (noatsign.com, user@.com, user@domain) to see which cases each pattern handles.
Phone Number Regex Patterns
Phone number formats vary enormously by country, so the right pattern depends on your target audience. Here are patterns for the most common cases. US/Canada (NANP) numbers in common formats: ^[+]?1?[-. ]?\(?[2-9]\d{2}\)?[-. ]?\d{3}[-. ]?\d{4}$ This accepts: (555) 867-5309 555-867-5309 555.867.5309 +1 555 867 5309 15558675309 The \(?[2-9]\d{2}\)? part requires the area code's first digit to be 2–9 (0 and 1 are not valid NANP area code starts), and makes the parentheses optional. For international numbers (less strict): ^[+]?[\d\s\-().]{7,20}$ This accepts 7 to 20 characters consisting of digits, spaces, hyphens, parentheses, and an optional leading +. It is intentionally loose, allowing a wide range of international formats without false rejections. For a digits-only format after stripping formatting: ^\d{10,15}$ — this is useful after you have stripped all non-digit characters with a replace operation. Practical advice: strip all non-digit characters before validation, then validate the digit count. Most international numbers are 7–15 digits. Store phone numbers as digit-only strings in your database to simplify sorting and formatting on output. Paste a variety of phone formats into the regex tester to see which pattern handles your expected input. Include edge cases: numbers with extensions (ext. 123), numbers with country codes, and numbers typed with various separators.
URL Validation and Parsing Regex
URLs are complex structures, and a fully RFC-compliant URL regex is hundreds of characters long. For practical web development purposes, simpler patterns that cover the common cases are more maintainable. Basic URL pattern (http and https): ^https?:\/\/(www\.)?[-a-zA-Z0-9@:%._+~#=]{1,256}\.[a-zA-Z0-9()]{1,6}\b([-a-zA-Z0-9()@:%_+.~#?&\/=]*)$ This pattern matches: https://example.com http://www.sub.domain.co.uk/path?query=value#fragment https://user:pass@example.com:8080/path For extracting URL components with capture groups: ^(https?):\/\/([^\/]+)(\/?.*?)([^\/?#]*)(#.*)?$ Group 1: scheme (http or https) Group 2: host (including port if present) Group 3: path Group 4: filename Group 5: fragment A simpler check — does this string look like it could be a URL: ^(https?|ftp):\/\/.+ For validating that a user-entered URL starts with a safe scheme (blocking javascript: URLs): ^(https?|ftp):\/\/ — this is a security-relevant check that should be performed server-side as well. URL validation is one area where using the browser's built-in URL constructor is often preferable to regex: try { new URL(input); return true; } catch { return false; }. Combine both approaches: use regex for quick user-facing feedback and the URL constructor for definitive validation in your validation logic.
Other Essential Patterns: Dates, IP Addresses, and Postal Codes
Beyond the big three, several other validation tasks come up regularly enough to warrant ready-made patterns. ISO 8601 date (YYYY-MM-DD): ^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$ This validates the format and range-checks months (01–12) and days (01–31). It does not check that February 30 is invalid — full calendar validation requires code logic. US ZIP code (5 or 9 digits): ^\d{5}(-\d{4})?$ IPv4 address: ^((25[0-5]|2[0-4]\d|[01]?\d\d?)\.){3}(25[0-5]|2[0-4]\d|[01]?\d\d?)$ The character classes ensure each octet is 0–255: 25[0-5] matches 250–255, 2[0-4]\d matches 200–249, [01]?\d\d? matches 0–199. Credit card (major networks, digits only): ^(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|3[47][0-9]{13}|6(?:011|5[0-9]{2})[0-9]{12})$ Visa starts with 4, Mastercard with 51–55, Amex with 34 or 37, Discover with 6011 or 65. Slug (URL-friendly string): ^[a-z0-9]+(?:-[a-z0-9]+)*$ This matches lowercase alphanumeric segments separated by single hyphens, with no leading or trailing hyphen. Paste each of these into the regex tester with valid and invalid examples. Pay particular attention to boundary cases — the largest valid value and one beyond it — to confirm your pattern's range logic is correct.
Frequently Asked Questions
- Should I validate email addresses strictly with regex?
- No. A strictly correct email regex based on RFC 5322 is extremely complex and still cannot verify deliverability. For user-facing forms, a simple pattern like ^[\w.+-]+@[\w-]+\.[a-zA-Z]{2,}$ is sufficient to catch obvious typos and reject strings that are clearly not email addresses. For anything beyond that — confirming the mailbox actually exists — send a confirmation email. Over-strict validation frustrates users with uncommon but valid address formats.
- What is the best way to validate phone numbers internationally?
- Use a two-step approach. First, strip all non-digit characters except a leading + sign. Then check that the resulting string is 7 to 15 digits long (the range of valid ITU-T E.164 international numbers). For applications where precise country-specific validation matters — billing, SMS delivery — use a dedicated library like Google's libphonenumber, which maintains a database of country-specific rules. Regex alone cannot reliably validate international numbers across all formats.
- Can I copy these patterns directly into my JavaScript code?
- Yes, with one adjustment for string literals. In a JavaScript regex literal (between forward slashes), backslashes do not need extra escaping: /^[\w.+-]+@[\w-]+\.[a-zA-Z]{2,}$/i. If you pass the pattern as a string to the RegExp constructor, each backslash must be doubled: new RegExp('^[\\w.+-]+@[\\w-]+\\.[a-zA-Z]{2,}$', 'i'). The regex tester uses regex literal syntax, so patterns you verify there can be copy-pasted into a regex literal without modification.