A regular expression (regex) is a sequence of characters that defines a search pattern for string matching. The concept was developed by mathematician Stephen Kleene in the 1950s as part of formal language theory. Ken Thompson implemented the first practical regex engine in the Unix text editor ed in 1969, and the technology has been built into virtually every programming language and text editor ever since.
The core syntax: a literal character matches itself. The dot (.) matches any single character except newline. Quantifiers control repetition: * means zero or more, + means one or more, ? means zero or one, and {n,m} means between n and m times. Anchors restrict match position: ^ matches the start of the string and $ matches the end. Character classes in square brackets ([abc]) match any one listed character; [^abc] matches any character not listed. The escape sequences \d (digit), \w (word character: letters, digits, underscore), and \s (whitespace) are shorthand for common character classes.
Parentheses create capture groups, extracting matched substrings for later use. The pipe (|) provides alternation — matching either the left or right expression. These primitives compose into patterns of arbitrary complexity for form validation, log parsing, data extraction, search-and-replace operations, and text transformation.
A developer needs to validate email addresses in a signup form before submitting to the server. She starts with the pattern /^[^\s@]+@[^\s@]+\.[^\s@]+$/. Breaking it down: ^ anchors to the start of the string. [^\s@]+ matches one or more characters that are not whitespace or @. The literal @ matches the at sign. Another [^\s@]+ matches the domain. \. matches a literal dot (the backslash escapes the dot, preventing it from matching any character). A final [^\s@]+ matches the TLD. $ anchors to the end of the string.
Testing against real inputs using this tool: user@example.com matches (valid structure), plainaddress does not match (missing @), @example.com does not match (nothing before @), user@example.co.uk matches (multiple dot segments allowed), user @example.com does not match (space in local part). She iterates on the pattern in the live tester, adjusting for her application's specific requirements, until all relevant edge cases behave correctly. The live highlighting shows exactly which characters each part of the pattern is matching, making debugging immediate rather than requiring repeated test runs.
Greedy vs lazy quantifiers: by default, quantifiers are greedy and match as many characters as possible. The pattern <.+> applied to <a>click here</a> matches the entire string from the first < to the last >, because .+ greedily consumes everything. Adding ? makes the quantifier lazy (<.+?>), matching only <a> — as few characters as possible while still satisfying the pattern. This distinction is critical when matching delimited content like HTML tags, quoted strings, or parenthesized expressions.
Lookahead and lookbehind assertions match positions rather than characters. A positive lookahead (?=...) asserts that the pattern inside must follow the current position without consuming characters. For example, \d+(?= dollars) matches a number only if followed by “ dollars”, without including “ dollars” in the match. Named capture groups (?<year>\d4) label captured substrings for reference by name rather than index, making complex patterns far more readable.
Catastrophic backtracking is a performance hazard. Some patterns with nested quantifiers — like (a+)+ — take exponential time on certain inputs. A 30-character input could cause the regex engine to evaluate billions of state combinations before reporting no match. ReDoS (Regular Expression Denial of Service) exploits this by sending inputs that trigger catastrophic backtracking in server-side regex validation. For web applications that accept and evaluate user-supplied patterns, always set a timeout or validate patterns against known-safe inputs before using them in production.
This regex tester lets you test regular expressions against any text instantly in your browser. Matches are highlighted in yellow as you type, with position and capture group details in the match list. The common patterns reference includes patterns for email, URL, phone, IP address, and date formats — click any to load it. All matching uses the native JavaScript RegExp engine. Your regex pattern and test data never leave your browser.
Paste your pattern into the regex field and your text into the test string area. Matches are highlighted in yellow in real time as you type (debounced 300ms). The match count is shown next to the label, and the match list below shows each match with its start and end index and any named capture groups.
g (global) finds all matches in the string — without it only the first match is returned. i (case insensitive) makes letter matching ignore case so "Hello" matches "hello". m (multiline) makes ^ match the start of each line and $ match the end of each line instead of just the whole string. s (dotAll) makes the . metacharacter match newline characters as well as all other characters.
Common causes: the g flag is off so only the first match shows; the pattern is anchored with ^ or $ which prevents partial string matches; special characters like . * + ? ( ) [ ] { } \ | ^ $ are not escaped with \; or the i flag is needed for case-insensitive matching. The error message shows JavaScript's native error for invalid patterns. Use the common patterns section for working examples.
No. All regex matching is performed locally using the JavaScript RegExp engine built into your browser. Your pattern and test string are never transmitted to any server. You can verify this by opening DevTools → Network tab while testing — there are zero outbound requests.
A capture group is a portion of a regex pattern enclosed in parentheses () that captures the matched text separately from the full match. For example, (\w+)@(\w+) captures the username and domain as separate groups. Named groups use the syntax (?<name>...) — for example (?<year>\d{4})-(?<month>\d{2}) captures a date with named groups "year" and "month" shown in the Groups column of the match list.