A note on context-dependence
Regex patterns are inherently context-dependent. There is no single "correct" pattern for an email address or a phone number — the right pattern depends on what inputs you accept, how strict your validation needs to be, and what you plan to do with mismatches.
The patterns here are practical starting points. Test them against real data from your application and adjust as needed. None of them should be treated as universal validation standards.
Digits and numbers
Any sequence of digits:
\d+
Matches: 42, 007, 12345
Integer — optional leading minus:
-?\d+
Matches: 42, -7, 0
Decimal number:
-?\d+(\.\d+)?
Matches: 3.14, -0.5, 100
Number with thousands separators (e.g. 1,000,000):
\d{1,3}(,\d{3})*
Matches: 1,000, 1,000,000
Words and identifiers
A single word (letters only):
\b[a-zA-Z]+\b
A word that starts with a capital letter:
\b[A-Z][a-z]+\b
camelCase identifier:
[a-z][a-zA-Z0-9]*
snake_case identifier:
[a-z][a-z0-9_]*
Hex colour code:
#[0-9a-fA-F]{6}
Matches: #3a7bd5, #FFFFFF
Whitespace
One or more whitespace characters:
\s+
Leading whitespace:
^\s+
Trailing whitespace:
\s+$
Multiple consecutive spaces (to collapse into one):
{2,}
Simple email pattern
Email addresses are notoriously difficult to validate with regex — the full specification is extremely complex. This pattern covers the vast majority of real-world addresses:
^[a-zA-Z0-9._%+\-]+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,}$
Matches: [email protected], [email protected]
Does not match: @example.com, user@, [email protected]
For production use, consider sending a confirmation email rather than relying on regex alone — even a perfectly formed address might not exist.
Dates
ISO 8601 date (YYYY-MM-DD):
^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$
Matches: 2024-03-15, 2000-12-31
US date format (MM/DD/YYYY):
^(0[1-9]|1[0-2])\/(0[1-9]|[12]\d|3[01])\/\d{4}$
Matches: 03/15/2024
Time in 24-hour format (HH:MM):
^([01]\d|2[0-3]):[0-5]\d$
Matches: 09:30, 23:59
URLs
Simple URL (http or https):
https?:\/\/[^\s]+
Matches most URLs in running text. This is intentionally loose — extracting URLs from prose is different from validating that a URL is well-formed.
URL with optional path and query:
^https?:\/\/([\.da-z\.-]+)\.([a-z\.]{2,6})([\/ \w\.-]*)*\/?$
This is stricter and better suited to validating a URL field in a form.
Phone-like patterns
Phone numbers vary enormously by country and formatting convention. These patterns match common formats rather than any official standard.
US phone number (common formats):
^(\+1[\s\-]?)?\(?\d{3}\)?[\s\-]?\d{3}[\s\-]?\d{4}$
Matches: 555-867-5309, (555) 867-5309, +1 555 867 5309
International format with country code:
^\+\d{1,3}[\s\-]?\d[\d\s\-]{7,14}\d$
This accepts +44 20 7946 0958 and similar — but it is a rough check, not a definitive validator.
Miscellaneous
IPv4 address:
^(\d{1,3}\.){3}\d{1,3}$
This matches the format but does not enforce the 0–255 range per octet. A stricter version:
^((25[0-5]|2[0-4]\d|[01]?\d\d?)\.){3}(25[0-5]|2[0-4]\d|[01]?\d\d?)$
Slug (URL-safe identifier):
^[a-z0-9]+(?:-[a-z0-9]+)*$
Matches: my-blog-post, product-v2
Non-empty string (no blank input):
\S+
Testing your patterns
Use the Regex Tester to paste a pattern and test it against real input. You can toggle flags (case-insensitive, global, multiline) and see matches highlighted live.
If you are new to regex syntax, see Regular Expressions Explained for Beginners for a breakdown of how each piece of syntax works.