Common Regex Patterns: Email, URL, Phone, IP, ISO Date

Quick refresher: the pieces

• ^ start of string, $ end of string. Use both to match the whole string, not just a substring.
• \d digit, \w word character ([A-Za-z0-9_]), \s whitespace.
• + one or more, * zero or more, ? optional, {n,m} bounded repetition.
• (...) capture group, (?:...) non-capturing group.
• Flags: i case-insensitive, g global (find all matches), m multiline, s dot matches newline.

Email address

The "correct" regex for RFC 5321 email is hundreds of characters and still wrong. For practical use:

/^[^\s@]+@[^\s@]+\.[^\s@]+$/

"Some non-whitespace-non-at-sign characters, an @, more of the same, a dot, more of the same." It accepts everything that looks like an email and rejects obvious garbage. It does not validate that the address is real, deliverable, or even syntactically perfect — only an SMTP server can do that. Use this for client-side hint validation; let the email-confirmation flow tell you whether the address actually works.

Common mistakes

• Disallowing + in the local part. Plus addresses ([email protected]) are valid and widely used.
• Disallowing dots in the local part. Also valid.
• Limiting the TLD to 4 characters. .museum is 6, .travel is 6, and many newer TLDs are longer.

URL (HTTP/HTTPS)

/^https?:\/\/[^\s/$.?#].[^\s]*$/i

"http or https, then ://, then a non-whitespace non-special character, then any non-whitespace." Matches typical URLs without false-positiving on text that contains http as a substring.

For real validation, use the URL constructor instead: try { new URL(input); } catch { /* invalid */ }. The URL constructor implements the WHATWG URL spec and is far more correct than any regex.

US phone number

/^\(?(\d{3})\)?[\s.-]?(\d{3})[\s.-]?(\d{4})$/

Matches (415) 555-1212, 415-555-1212, 415.555.1212, 4155551212, etc. Capture groups give you area code, exchange, and subscriber number for normalization.

For international phone numbers, don't roll your own — use a library like libphonenumber (Google's). Phone formats vary so much by country that any regex you write will be wrong somewhere.

IPv4 address

/^((25[0-5]|2[0-4]\d|[01]?\d\d?)\.){3}(25[0-5]|2[0-4]\d|[01]?\d\d?)$/

Validates each octet is 0–255 (not just 0–999). The simpler /^\d{1,3}(\.\d{1,3}){3}$/ matches "999.999.999.999" which isn't a valid IP.

IPv6 address

The full IPv6 grammar with shorthand (::) and embedded IPv4 mappings is several hundred characters. For the common case:

/^[0-9a-f]{1,4}(:[0-9a-f]{1,4}){7}$/i

Matches the fully-expanded form (2001:0db8:0000:0000:0000:ff00:0042:8329) but not the shorthand. If you need real IPv6 parsing, use a library; the shorthand rules are subtle.

ISO 8601 date / datetime

/^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])(T\d{2}:\d{2}(:\d{2}(\.\d+)?)?(Z|[+-]\d{2}:\d{2})?)?$/

Matches 2026-05-03, 2026-05-03T14:30:00Z, 2026-05-03T14:30:00+02:00. Doesn't catch invalid date combinations like Feb 30; use new Date(input) and check that the parsed date round-trips to the same ISO string.

Hex color

/^#?([0-9a-f]{3}|[0-9a-f]{4}|[0-9a-f]{6}|[0-9a-f]{8})$/i

Accepts 3, 4, 6, or 8-digit hex (with or without leading #). The 4-digit and 8-digit variants include alpha. To convert any of these to RGB or HSL, paste them into our color converter.

UUID v4

/^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i

Validates the version-4 UUID structure including the version digit (4) and variant bits ([89ab]). For other UUID versions, replace the 4 after the third dash with the appropriate digit, or drop the version constraint with [0-9a-f].

Slug (URL-safe path segment)

/^[a-z0-9]+(?:-[a-z0-9]+)*$/

Lowercase letters, digits, and single hyphens — no leading, trailing, or consecutive hyphens. The convention every modern URL uses for "kebab-case" path segments.

Strong password (heuristic)

/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[^A-Za-z\d]).{12,}$/

At least 12 characters, with at least one lowercase, one uppercase, one digit, and one symbol. Lookaheads ((?=...)) check each requirement independently. Note: complexity rules like this are increasingly seen as outdated — NIST now recommends length over character variety. Generate strong passwords with our password generator.

Common pitfalls

Catastrophic backtracking

Patterns like (a+)+b (or anything with nested quantifiers and ambiguity) can take exponential time on inputs that don't match. If your regex is fed user input, fuzz-test it with long non-matching strings. The regex tester will reveal slow patterns interactively.

Forgetting the anchors

/\d{3}/ matches "123" inside "abc123def". To validate a whole string is just three digits, use /^\d{3}$/.

Using regex when a parser exists

For URLs, JSON, HTML, dates, phone numbers — there's almost always a real parser in your standard library that handles edge cases regex can't. Reach for the parser; reach for regex when you genuinely have a free-form string and a clear pattern.

Test interactively

Patterns above are starting points, not finished products. Use our regex tester to paste a pattern, paste sample input, and see matches and capture groups in real time. It supports JavaScript regex syntax, all flags, and a replace mode for substitution patterns.