Technical Reference
RegexLab Technical Documentation
Engineered and documented by Melalew Mengistu, Cybersecurity Researcher and Web Engineer at MELEX IT.
What Is a Regular Expression?
A regular expression (regex) is a formal sequence of characters that defines a search pattern. Originating from theoretical computer science and formal language theory, regex engines implement deterministic finite automata (DFA) or non-deterministic finite automata (NFA) to traverse input strings and locate pattern matches. JavaScript's built-in RegExp engine uses a backtracking NFA, which gives it expressive power but also introduces performance risks that every developer and security engineer must understand.
RegexLab runs your patterns and test text entirely in your browser using the native JavaScript RegExp API. No input is transmitted to any server. Pattern execution times displayed in the Statistics panel reflect real browser performance, making this tool useful for diagnosing inefficient patterns before deploying them in production code.
Regex Syntax Deep Dive
Anchors and Boundaries
The ^ anchor asserts position at the start of the string. With the multiline flag m enabled it matches the start of each line. Similarly, $ asserts the end. The word boundary \b is a zero-width assertion between a word character (\w) and a non-word character. Security note: validators that rely on ^ and $ without the multiline flag may behave differently across regex engines — a pattern that correctly anchors in JavaScript may not anchor in PHP's PCRE or Python's re module in the same way.
Capturing Groups and Named Groups
Parentheses (abc) create a numbered capturing group. Groups are indexed left-to-right starting at 1. Named groups (?<name>abc) allow you to reference captures by descriptive labels in code — for example, (?<year>\d{4})-(?<month>\d{2}) makes date parsing code more readable and maintainable. Non-capturing groups (?:abc) group tokens for quantifiers without creating a capture slot, which reduces memory allocation in tight loops.
Lookaheads and Lookbehinds
Lookaround assertions match a position without consuming characters. They are zero-width assertions — they do not form part of the matched text:
(?=…)Positive lookahead — position must be followed by the pattern.(?!…)Negative lookahead — position must NOT be followed by the pattern.(?<=…)Positive lookbehind — position must be preceded by the pattern.(?<!…)Negative lookbehind — position must NOT be preceded by the pattern.
A practical security use case for lookbehinds: extracting numeric values preceded by a dollar sign without capturing the sign itself — (?<=\$)\d+(\.\d{2})?. This is cleaner than capturing and discarding the first group.
ReDoS: Catastrophic Backtracking & Client-Side Security
Regular Expression Denial of Service (ReDoS) is a vulnerability class caused by poorly designed regex patterns that force a backtracking NFA engine to explore an exponential number of paths before declaring a non-match. The canonical example is the pattern (a+)+ applied to a string like aaaaaaaaaaaaaaab. The engine must try every possible grouping of the a characters before failing, which scales as O(2ⁿ) with input length.
Common patterns that cause catastrophic backtracking include: nested quantifiers like (\w+\s?)+, alternation with overlapping cases like (a|aa)+, and overly broad wildcard quantifiers such as .*.*.* applied to long inputs.
In a browser context, a ReDoS attack can freeze a user's tab when attacker-controlled input is validated client-side against a vulnerable regex. Server-side, it can cause CPU exhaustion on Node.js request handlers or Python web frameworks that block the event loop. Use RegexLab's Exec Time stat to identify patterns that slow down unexpectedly with long inputs before shipping them to production.
Mitigation strategies: Prefer possessive quantifiers or atomic groups where the engine supports them. Use explicit character classes instead of .* wildcards. Apply input length limits before regex validation. Consider DFA-based engines like RE2 (used by Google) for untrusted input in server applications — RE2 guarantees linear time matching by forbidding backtracking features.
Security Validation Patterns Reference
The following patterns are commonly used in security-sensitive input validation. Each balances strictness against practical compatibility. Load any of them directly using the Quick Examples panel above.
-
Email Address
[\w.+-]+@[\w-]+\.[\w.]+
Covers local parts with dots, plus-addressing, and subdomains. For RFC 5322 full compliance, use a dedicated parsing library rather than regex — the full RFC grammar is not safely expressible without catastrophic backtracking risk.
-
IPv4 Address
^(?:(?:25[0-5]|2[0-4]\d|[01]?\d\d?)\.){3}(?:25[0-5]|2[0-4]\d|[01]?\d\d?)$
Strictly validates each octet in range 0–255. A simple \d{1,3} pattern would match 999.999.999.999 — a common security oversight in allowlist rules and firewall filters.
-
TLS Certificate SAN / Hostname
^(\*\.)?([a-zA-Z0-9]([a-zA-Z0-9\-]{0,61}[a-zA-Z0-9])?\.)+[a-zA-Z]{2,}$
Validates hostnames and wildcard SANs per RFC 1123. Useful for verifying Subject Alternative Name entries when parsing certificate data programmatically or building certificate transparency log analyzers.
-
Strong Password (NIST-aligned)
(?=.*[A-Z])(?=.*[a-z])(?=.*\d)(?=.*[!@#$%^&*]).{12,}
Uses four positive lookaheads to enforce character class diversity. Note that NIST SP 800-63B (2017) recommends focusing on length (minimum 8, ideally 12+) and blocking known-breached passwords rather than mandatory complexity rules, which users often satisfy minimally.
-
SQL Injection Basic Probe Detection
(['";]|(-{2})|(/\*)|(xp_)|(UNION\s+SELECT)|(DROP\s+TABLE))
A heuristic probe-detection pattern — not a replacement for parameterized queries. Useful for WAF rule drafting and log analysis to identify suspicious inputs. Case-insensitive flag i is essential since SQL keywords are case-insensitive.
Regex Flags in JavaScript
JavaScript supports six regex flags, each modifying engine behavior. Misapplying flags is a common source of security bugs and logic errors:
gGlobal — find all matches, not just the first. Required for matchAll(). Caution: test() with a global regex advances lastIndex, causing alternating true/false returns on repeated calls — a notorious JavaScript gotcha.iCase-insensitive — essential for security pattern matching since attackers routinely vary casing to bypass naive string filters.mMultiline — makes ^ and $ match line boundaries. Without it, these anchors only match the full string boundary.sDotAll — makes . match newline characters. Useful for multi-line HTML/log parsing but dangerous in validators — an overly broad .* with s can cross intended line boundaries.uUnicode — enables full Unicode code point matching. Required to correctly handle emoji and characters outside the Basic Multilingual Plane. Without it, \uD83D surrogate halves are treated as separate characters, causing incorrect length calculations in security validators.ySticky — matches only from lastIndex position, not anywhere in the string. Used for building tokenizers and parsers where position continuity matters.
Further Reading
Regex is a foundational tool in both web security research and application development. These articles from MELEX IT explore related practical topics in depth: