Free Regex Tester

Each flag changes how the regex engine processes the pattern. g (global) finds all matches in the string instead of stopping at the first. i (case-insensitive) treats uppercase and lowercase letters as equivalent, /abc/i matches "ABC", "Abc", and "abc". m (multiline) makes ^ and $ match the start and end of each line, not just the start and end of the entire string. s (dotall) makes the dot (.) match newline characters (\n), which it normally skips. u (unicode) enables full Unicode matching, treating surrogate pairs as single code points and enabling \p{...} property escapes for matching categories like letters, numbers, or scripts. y (sticky) forces the match to start at the exact position of lastIndex, useful for tokenizers and parsers that process input sequentially.

Capture groups are parts of the regex enclosed in parentheses (). They let you extract specific portions of a match. For example, (\d{4})-(\d{2})-(\d{2}) applied to "2026-04-05" captures "2026" in group 1, "04" in group 2, and "05" in group 3. Named capture groups use the syntax (?<year>\d{4})-(?<month>\d{2})-(?<day>\d{2}), letting you reference captures by name (match.groups.year) instead of by index. Named groups make complex patterns far more readable and maintainable. Non-capturing groups (?:...) group tokens without creating a capture, which is useful when you need grouping for alternation or quantifiers but do not need the matched text.

Lookahead and lookbehind are zero-width assertions, they check whether a pattern exists before or after the current position without consuming characters. Positive lookahead (?=...) matches if the pattern ahead exists: \d+(?= dollars) matches "100" in "100 dollars" but not in "100 euros". Negative lookahead (?!...) matches if the pattern ahead does not exist. Positive lookbehind (?<=...) matches if the pattern behind exists: (?<=\$)\d+ matches "50" in "$50". Negative lookbehind (?<!...) matches if the pattern behind does not exist. Lookbehind was added in ECMAScript 2018 and is supported in all modern browsers (Chrome, Firefox, Safari 16.4+, Edge).

Here are practical patterns: Email (basic): ^[a-zA-Z0-9._%+\-]+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,}$, matches standard email format. URL: ^https?:\/\/[\w\-]+(\.[\w\-]+)+[\/\w\-.,@?^=%&:~+#]*$, matches HTTP and HTTPS URLs. US phone: ^(\+1[\s.-]?)?\(?\d{3}\)?[\s.-]?\d{3}[\s.-]?\d{4}$, matches formats like (555) 123-4567 and +1-555-123-4567. IPv4: ^((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. Date (YYYY-MM-DD): ^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$. These patterns validate format only, they do not verify that an email domain exists or a date is real.

Catastrophic backtracking occurs when a regex engine takes an exponentially long time to determine that a string does not match a pattern. It happens with nested quantifiers like (a+)+ or patterns where many paths must be explored before failing. For example, the pattern (a+)+b against the string "aaaaaaaaaaaaaaaaac" forces the engine to try billions of combinations before concluding there is no match, potentially freezing your browser tab. To avoid it: (1) never nest quantifiers without constraints, use a+ instead of (a+)+, (2) use atomic grouping or possessive quantifiers in engines that support them, (3) make patterns fail fast by anchoring them or using more specific character classes, and (4) test your patterns against long strings that should not match to catch performance issues early.

The most significant differences: PCRE (used by PHP, R, and many tools) supports recursive patterns (?R), conditional expressions (?(id)yes|no), possessive quantifiers (a++), atomic groups (?>...), and variable-length lookbehind, none of which are available in JavaScript. Python re uses (?P<name>...) syntax for named groups instead of JavaScript (?<name>...) and supports the VERBOSE flag for inline comments. .NET regex supports balancing groups for matching nested structures and right-to-left matching. JavaScript lacks all of these but has excellent Unicode support via the u flag and \p{} property escapes. For most everyday patterns, character classes, quantifiers, alternation, lookahead, basic lookbehind, and capture groups, all engines behave identically.

Yes, with the u (unicode) flag enabled. Without the u flag, JavaScript treats strings as sequences of 16-bit code units, which means characters outside the Basic Multilingual Plane (like emoji) are seen as two separate surrogate code units. With the u flag, surrogate pairs are treated as single code points, and you can use Unicode property escapes: \p{Letter} matches any letter in any script, \p{Emoji} matches emoji, \p{Script=Greek} matches Greek characters, and \p{Number} matches digits in any numeral system. You can also use \u{1F680} to match specific code points. The v flag (unicodeSets), added in ECMAScript 2024, extends this further with set operations for character classes.

Regex101 is the most feature-rich online regex tester, it supports multiple engines (PCRE, Python, JavaScript, Go, Java, C#, Rust), provides a plain-English explanation of your pattern, generates code snippets, and has a community pattern library. RegExr focuses on learning with a built-in cheat sheet and community patterns. Both tools send your patterns and test strings to a server for processing. This tool is deliberately simpler and prioritizes privacy: all matching happens locally in your browser, your data never touches a server, and there is nothing to sign up for. If you need multi-engine support or pattern explanations, use regex101. If you want a fast, private tester for JavaScript regex, this tool is the better choice.

For basic and intermediate patterns, character classes, quantifiers, alternation, anchors, lookahead, capture groups, JavaScript regex behaves identically to Python re, PCRE (PHP), Java, and Go. You can confidently test these patterns here. However, if your pattern uses engine-specific features like PCRE recursive patterns, Python verbose mode, .NET balancing groups, or Java possessive quantifiers, the behavior will differ. For those cases, test in the target language directly or use a multi-engine tool like regex101.com. As a rule of thumb: if your pattern works here and does not use features specific to another engine, it will work in your target language.

Backreferences let you match the same text that was previously captured by a group. The syntax \1 refers to the text captured by the first group, \2 to the second, and so on. For example, (\w+)\s+\1 matches a repeated word like "the the", the \1 must match exactly the same text as the first capture group. With named groups, you can use \k<name> as a backreference: (?<word>\w+)\s+\k<word>. Backreferences are useful for detecting duplicates, matching paired delimiters (like matching an opening and closing HTML tag), and validating symmetric patterns. Note that backreferences make the regex non-regular in the formal computer science sense, they add computational power beyond what a finite automaton can handle.

Start with literal character matching and build up incrementally. Learn character classes first (\d for digits, \w for word characters, \s for whitespace, . for any character), then quantifiers (+ for one or more, * for zero or more, ? for optional, {n,m} for a range). Next learn anchors (^ for start, $ for end, \b for word boundary) and alternation (|). Practice with real tasks, matching email addresses, extracting dates from text, or finding URLs in a log file. Once comfortable, learn groups and backreferences, then lookahead and lookbehind. This tool is ideal for learning because you see results instantly, every change to your pattern updates the highlighted matches in real time. Recommended resources include regular-expressions.info for comprehensive reference and javascript.info/regular-expressions for JavaScript-specific tutorials.

By default, quantifiers in regex are greedy, they match as much text as possible. The pattern <.+> applied to "<b>bold</b>" matches the entire string "<b>bold</b>" because .+ consumes everything and only backtracks enough to find the last >. Adding a ? makes the quantifier lazy (also called reluctant), it matches as little text as possible. The pattern <.+?> matches "<b>" and "</b>" separately because .+? stops at the first >. Lazy quantifiers are essential when extracting content between delimiters. The same ? modifier works on all quantifiers: *? (lazy star), +? (lazy plus), ?? (lazy optional), and {n,m}? (lazy range). Understanding greedy vs. lazy behavior is one of the most important regex concepts for avoiding unexpected matches.