Regex Tester: 7 Patterns Every Developer Should Know

Regex is one of those skills that 80% of developers learn 20% of, then re-Google the same patterns every time they need them. This post collects the seven regex patterns that come up most often in real work, each one with a live-testable example, the gotchas that bite first-timers, and when to NOT use regex at all.

Every pattern below can be tried instantly in our Regex Tester — paste the pattern, paste sample text, see matches highlighted with capture groups labeled. No signup, no install.

1. Email validation

The pragmatic email regex:

^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$

What it catches: standard [email protected] formats, plus most professional variants with dots, plus signs, and underscores in the local part.

What it misses (and why that's fine): the full RFC 5322 email grammar allows quoted local parts, embedded dots in odd places, and exotic IPv6 domains. A complete RFC-compliant regex is roughly 6,000 characters and still cannot fully validate an email is real. The right validation strategy is: regex for syntax, then send a verification email. The above pattern is the sweet spot — it rejects obvious garbage, accepts every email people actually use, and stays readable.

Common gotchas:

• ^ and $ anchors are mandatory — without them, [email protected] extra junk matches.
• The \. escape for the TLD dot is required. Bare . matches any character, which would accept foo@bar9com as valid.
• TLD length minimum {2,} matters because old {2,4} ranges reject newer TLDs like .travel or .museum.

2. URL extraction

For finding URLs in arbitrary text (logs, comments, chat messages):

https?://[^\s<>"']+

What it catches: any http:// or https:// URL up to the first whitespace or quote character. Captures query strings, fragments, and path components.

Why no www. prefix: the protocol prefix is a more reliable URL boundary in messy text than www.. Modern URLs often skip the www. subdomain entirely.

Gotchas:

• Trailing punctuation problem: Check https://example.com. captures the period. Add a stripping pass for trailing ., ,, ;, ), ] in post-processing.
• For validating a URL is well-formed, use the built-in URL constructor in JavaScript or urllib.parse in Python — they do real parsing, not pattern matching.

3. Strong password validation

For client-side hints during signup (server must re-validate):

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

What it requires: at least one lowercase letter, one uppercase letter, one digit, one special character, and a minimum length of 12. Uses lookaheads (?=...) to check each requirement independently.

Modern thinking on password rules: NIST 800-63B (the US government password standard) actually recommends AGAINST forcing character-class complexity rules because they push users toward predictable patterns like Password1!. NIST recommends length-only checks (8 minimum, ideally 16+) combined with blocklist of leaked passwords (HaveIBeenPwned API).

So use this pattern when your auditor or framework requires the classic mixed-character rule. Use a simpler .{12,} plus a HIBP blocklist when you have freedom to design the policy.

Gotchas:

• Lookaheads do not consume input — they assert. Beginners often confuse (?=.*[a-z]) with .*[a-z] (which fails the whole match if the lowercase isn't followed by valid suffix).
• This pattern allows spaces. If you want to ban whitespace, add (?!.*\s).

4. IPv4 address

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

What it catches: valid dotted-quad IPv4 addresses where each octet is 0-255.

Why the verbose pattern: the naive ^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$ accepts 999.999.999.999 which is not a valid IPv4. The alternation (25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?) correctly bounds each octet to 0-255.

Use cases: validating allowlists in config files, parsing IPs from log lines, filtering log destinations by IP range.

Gotchas:

• This does not validate IPv6 — that's a separate pattern roughly 5x more complex.
• It accepts 0.0.0.0 and 255.255.255.255, which are syntactically valid but special — broadcast, listen-all, etc. Application logic must filter further if those mean something specific.

5. UUID v4

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

What it catches: properly-formatted UUID v4 (random) with the version digit (4) and variant digit (8, 9, a, or b) in the right positions.

Why version-aware: v1, v3, v4, v5 UUIDs all share the same overall shape (8-4-4-4-12 hex chars) but encode different things in the version and variant nibbles. If you specifically want v4 (random), this pattern enforces that. For "any UUID format", relax the version digit to [1-5].

Gotchas:

• Most APIs return lowercase UUIDs but some use uppercase. Add i flag or expand to [0-9a-fA-F] to accept both.
• The hyphens are part of the canonical form. If you receive a UUID without hyphens (32 contiguous hex chars), strip-then-validate or write a separate pattern.

6. Phone number (international)

^\+?[1-9]\d{6,14}$

What it catches: E.164-style international phone numbers — optional leading +, then 7-15 digits, first digit non-zero.

Why this simple pattern beats elaborate country-specific ones: phone numbers are insanely diverse. US 10-digit, UK 11-digit-with-leading-0, Indian 10-digit-without-leading-0, French formats with spaces, Brazilian with country code — every country has multiple formats. The E.164 canonical form (digits only, with country code) is the only universal format. Validate to that, normalize on input, and store canonically.

For per-country formatting validation, use a dedicated library: libphonenumber (Google's open-source library, also exists for Python/Ruby/JS/etc.). It encodes the rules for every country and handles formatting concerns regex cannot.

Gotchas:

• This pattern does not validate that the number actually belongs to a real subscriber — only that the format is plausible. For real validation, use Twilio Lookup API, Telesign, or similar.
• Watch for inputs with formatting: (555) 123-4567. Strip non-digits before validating.

7. ISO 8601 date

^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$

What it catches: ISO 8601 dates in YYYY-MM-DD format with month 01-12 and day 01-31.

What it does not catch: invalid date combinations like February 30 or April 31. The regex cannot tell that 2026-02-31 is impossible because regex has no calendar awareness. For full date validation, parse with the language's date library and check that the round-trip produces the same string:

const isValidIsoDate = (s) => {
  const d = new Date(s);
  return d.toISOString().slice(0, 10) === s;
};

Gotchas:

• This is date-only. For full datetime (2026-05-28T14:30:00Z), append a separate datetime pattern.
• Allows future dates and 1000-year-old dates equally. Application logic must enforce business-meaningful bounds.

When to NOT use regex

Three places where regex looks tempting but is the wrong answer:

Parsing HTML. Browser DOM and CSS selectors exist for this. The infamous "you can't parse HTML with regex" Stack Overflow answer is correct — HTML's nested, context-sensitive grammar exceeds regex's expressive power. Use a real parser.

Parsing JSON/XML/YAML. Same reason. Use the language's native parser.

Email deliverability. Regex tells you the syntax is plausible. It does not tell you the address accepts mail, has not bounced, or is not a typo. For deliverability, integrate with a verification service.

How to use the regex tester effectively

Open the Regex Tester in another tab. Test each pattern above with both passing and failing examples:

• Email: test [email protected] (pass), [email protected] (fail), foo@bar (fail).
• URL: test the URL from this page, plus notaurl, plus an URL with trailing punctuation.
• Password: test Password1! (fails — too short), MyP@ssw0rdLong (passes), and the longest string you can think of.

The tester shows match positions, capture groups, and explains each token in your pattern. For learning, it's faster than reading docs.

Related tools and reading

• Regex Tester — the actual live testing tool
• Developer Tools Hub — full set of HTML/CSS/JS utilities including this regex tester
• Encoder/Decoder Tools — for the encoding contexts where regex often appears
• Security & Hash Tools — for password and hashing workflows that interact with the password regex above