Regex Tester

When Regular Expressions Are the Right Tool

Regular expressions earn their place in four recurring scenarios: log parsing, input validation, search-and-replace transforms, and data extraction from semi-structured text. Extracting ISO timestamps from nginx access logs, validating that an input matches an IPv4 pattern, reformatting date strings from MM/DD/YYYY to YYYY-MM-DD, or pulling all URLs from a block of HTML comments — these are tasks where a single well-crafted pattern replaces dozens of lines of imperative string manipulation.

The line between 'right tool' and 'wrong tool' runs through parsing. Regular expressions are finite automata — they can only recognise regular languages. HTML, XML, JSON, and most programming languages are context-free grammars, meaning they have nested, recursive structure that a regex engine fundamentally cannot track. Trying to parse HTML with regex is the classic failure case: it works on simple inputs, breaks on edge cases, and becomes unmaintainable. Use a proper parser (DOMParser for HTML, JSON.parse for JSON, tree-sitter for code) whenever structure is nested or recursive.

For everything else, keep patterns focused and well-anchored. A regex that validates input should be anchored with ^ and $ so it cannot match a substring of invalid input. Prefer non-capturing groups (?:...) when you do not need the captured value — it is faster and makes the intent clear. Add verbose comments when patterns grow complex; JavaScript does not have an 'x' flag for whitespace-insensitive mode, but wrapping a pattern in a string and using String.raw keeps it readable.

Commonly Used Regex Patterns

Treat these as starting points, not production-ready validators. Email validation in particular is a rabbit hole — for critical paths, send a verification email rather than trying to validate the format perfectly.

// Basic email validation (not RFC 5322 complete, but catches 99% of typos)
const email = /^[^s@]+@[^s@]+.[^s@]+$/;

// IPv4 address
const ipv4 = /^((25[0-5]|2[0-4]d|[01]?dd?).){3}(25[0-5]|2[0-4]d|[01]?dd?)$/;

// ISO 8601 date (YYYY-MM-DD)
const isoDate = /^d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]d|3[01])$/;

// HTTP/HTTPS URL
const url = /^https?://([w-]+.)+[w-]+(/[w-./?%&=]*)?$/i;

// CSS hex color (#rgb, #rrggbb, #rrggbbaa)
const hexColor = /^#([0-9a-f]{3}|[0-9a-f]{6}|[0-9a-f]{8})$/i;

// Usage
email.test('user@example.com');   // true
isoDate.test('2024-02-29');       // true (leap year check not included)
hexColor.test('#ff6600');         // true

Regex Performance Traps

• Catastrophic backtracking: patterns like (a+)+ or (a|a)+ cause exponential time on non-matching input because the engine explores an exponential number of paths — test all patterns against inputs designed to fail.
• Nested quantifiers on overlapping character classes: /([a-z]+)*$/ is the canonical ReDoS (Regular Expression Denial of Service) pattern; an attacker can craft input that hangs a Node.js server.
• Greedy .* across long strings: .* can match the entire input before backtracking; use .*? (lazy) or anchor with specific character classes when you know the shape of what you want.
• Unnecessary capture groups: every (...) without ?: allocates a capture slot and adds overhead; use non-capturing (?:...) when you only need grouping for alternation or quantifiers.
• Recompiling patterns in hot loops: create RegExp objects outside loops with const pattern = /foo/g and reset lastIndex manually rather than reconstructing on each iteration.