What is catastrophic backtracking and how do I avoid it?

Catastrophic backtracking occurs when a regex engine tries exponentially many ways to match a pattern that can never succeed. Classic example: the pattern (a+)+b against the string "aaaaaaaaac". The engine tries every possible way to divide the "a"s between the inner and outer quantifier — O(2^n) steps — before finally giving up. Fixes: (1) use possessive quantifiers (a++b) if your engine supports them; (2) use atomic groups ((?>a+)b); (3) rewrite the pattern to avoid nested quantifiers; (4) set a backtracking limit in engines that support it (PCRE, Python regex with timeout).

How do capturing groups work?

Parentheses in regex both group patterns and capture the matched text. Group 0 is always the full match. Subsequent groups are numbered by the order of their opening parenthesis, left to right. Non-capturing groups (?:...) group without capturing. Named groups (? ...) capture under a descriptive key. After a match, you can access groups by number or name — in JavaScript, match[1] for group 1, match.groups.name for named groups.

What is the difference between greedy and lazy quantifiers?

Greedy quantifiers (*, +, ?, {n,m}) match as many characters as possible while still allowing the overall pattern to match. Adding a ? after a quantifier makes it lazy (*?, +?, ??, {n,m}?) — it matches as few characters as possible. For example, with the string "<div>hello</div><div>world</div>", the pattern <div>.*</div> (greedy) matches the entire string in one match, while <div>.*?</div> (lazy) correctly matches each div pair separately.

Can regex parse HTML?

No — or more precisely, regex cannot reliably parse arbitrary HTML. HTML is not a regular language; it is context-free (or context-sensitive in some interpretations). Nested tags, attribute variations, CDATA sections, and HTML comments all defeat even sophisticated regex patterns. Use an HTML parser (like DOMParser in the browser or BeautifulSoup in Python) for reliable HTML parsing. Regex is fine for simple extraction from known, controlled HTML snippets but should not be the primary tool for parsing web pages.

How do I test my regex against the regex101.com test suite?

While regex101.com is the most popular online regex tester with community-contributed patterns, our built-in tester provides the same core features — real-time highlighting, capture group visualization, and multi-flavor support — with the added advantage of keeping your test data private (no server uploads) and offering direct integration with our other developer tools. You can export your saved patterns from regex101 and import them into our tester for offline or private use.

Developer Tools2026-05-10

Regular Expression Tester: Build, Test, and Debug Regex Online

A regular expression is a pattern-matching language that can find, extract, validate, and replace text with precision no amount of manual string manipulation can match. But writing regex is hard — a single misplaced quantifier turns a precise pattern into a performance bomb or a silent mismatch. Our regex tester lets you write a pattern, paste or type test data, and see real-time matches highlighted as you type. It supports JavaScript (ECMAScript 2024) syntax by default, with toggleable flavors for PCRE2 (PHP), Python 3, Java, and .NET — each of which handles features like lookbehind, Unicode property escapes, and backtracking control differently. The tool visualizes capture groups in distinct colours, flags the exact character position of the first match, and warns when your pattern risks catastrophic backtracking (e.g., (a+)+b matching against "aaaaaaaaac" — which can freeze a thread at 25 characters and take longer than the age of the universe at 30). Whether you are writing validation rules for a form, parsing log files, or refactoring code with find-and-replace, testing your regex interactively saves time and prevents costly errors.

manage_search

Regex Tester

Free · No registration

Try this tool for free →open_in_new

Step-by-Step Guide

Write Your Regex Pattern

Type your regular expression in the pattern field. The tool accepts literal regex (between forward slashes, e.g., /pattern/g) or a bare pattern string. A quick-reference sidebar lists common tokens — character classes (d, w, s), quantifiers (*, +, ?, {n,m}), anchors (^, $, ), and groups (capturing, non-capturing, named). Hovering any token displays a tooltip with its meaning and an example.

Paste Test Data and See Matches

Paste your test text — sample API responses, log output, user input, or code — into the test data area. Matches appear highlighted in real time as you type or modify the pattern. Each capture group is colour-coded: group 0 (full match) in blue, group 1 in green, group 2 in orange, and named groups show their name in the legend. Match positions (start/end index) are displayed below.

Toggle Flags and Regex Flavor

Enable flags using checkboxes: g (global — find all matches, not just the first), i (case-insensitive), m (multiline — ^ and $ match at line boundaries, not just the start/end of the whole string), s (dotall — . matches newline characters), u (Unicode — enables \u{...} and Unicode property escapes), and y (sticky). Switch the regex engine flavor via the dropdown to ensure your pattern works correctly in your target environment.

Tips & Best Practices

check_circle

The single most common regex performance killer is catastrophic backtracking — when a pattern with nested quantifiers (like (a+)+b) tries every possible way to partition the input before failing. For a 25-character input of "a"s, this can require over 33 million backtracking steps. Fix it by using possessive quantifiers (a++b) or atomic groups ((?>a+)b) where your engine supports them, or rewrite the pattern to be more specific.

check_circle

Lazy quantifiers (*?, +?, ??, {n,m}?) match as few characters as possible rather than as many as possible. They are essential when matching delimited content — for example, /<p>.*?</p>/ matches each paragraph tag pair instead of matching from the first <p> to the last </p> (which greedy .* would do).

check_circle

Lookahead and lookbehind assertions let you match text based on what comes before or after it without including that context in the match. Positive lookahead: /foo(?=bar)/ matches "foo" only when followed by "bar." Negative lookbehind: /(?<!\\)$/ matches a dollar sign only when it is not preceded by a backslash. JavaScript added lookbehind support in ES2018.

check_circle

Named capture groups make regex dramatically more readable. Instead of /(d{4})-(d{2})-(d{2})/ with numeric group references, use /(?<year>d{4})-(?<month>d{2})-(?<day>d{2})/ and reference groups by name: match.groups.year. Python, JavaScript, PCRE, and .NET all support this syntax.

check_circle

Unicode property escapes (p{...}) let you match entire character classes without listing every character individually. For example, p{Script=Han} matches any Chinese character, p{Emoji} matches emoji, and p{Lu} matches uppercase letters in any script. This is far more robust than trying to list Unicode ranges manually.

check_circle

For email validation, the only correct regex per RFC 5322 is over 200 characters long and still imperfect. For practical form validation, use a simple pattern like /^[^s@]+@[^s@]+.[^s@]+$/ as a first pass, then send a confirmation email. Do not try to validate every edge case of the email spec with regex — it is not the right tool for that job.

check_circle

Flags change regex behaviour significantly. The g flag runs a global search (multiple matches). Without it, only the first match is returned. The u flag enables full Unicode support — without it, patterns like /w{2,}/ may behave unexpectedly with non-ASCII characters. Always set the u flag for modern JavaScript regex unless you are sure you do not need Unicode.

check_circle

Test your regex against edge cases, not just happy-path inputs. An empty string, a string with only special characters, a maximally long string, and Unicode text can all expose flaws. The regex tester lets you save test case sets and run all of them against a pattern at once.

Frequently Asked Questions

While the core regex syntax (d, +, *, ^, $, groups) is universal, each engine has unique features and quirks. PCRE2 (used by PHP and many CLI tools) supports recursive patterns, possessive quantifiers, and callouts. JavaScript (ECMAScript) lacks possessive quantifiers and Q...E quoting but has lookbehind (ES2018). Python supports named groups with (?P<name>...) — different from JavaScript's (?<name>...). Java requires double-escaping backslashes in string literals (d becomes \\d in code). .NET supports balancing groups for matching nested structures.

Regex is one of the most powerful tools in a developer's toolkit — and one of the most error-prone. Interactive testing catches the silent mismatches, the backtracking bombs, and the cross-engine incompatibilities before they reach production. Our free regex tester supports four major engine flavors and runs entirely in your browser. Start testing your patterns now.

Try this tool for free →open_in_new