What Is a Regular Expression?
A regular expression is a pattern-matching language for describing a set of strings. As a regex tester online, this tool takes a pattern and sample text and shows, live, exactly what matched: every match highlighted directly in the text, with numbered and named capture groups broken out underneath. It works as a javascript regex tester specifically, using the browser's native RegExp engine, so results here match exactly what your own JavaScript code would produce when you test regex against real input. Think of it as a regex checker and a regular expression tester in one: type a pattern, paste text, and see matches update as you type either field.
Regex Flags Explained (g, i, m, s, u)
This tool supports the five flags JavaScript's RegExp actually implements. g (global) finds every match instead of stopping at the first. i (case insensitive) ignores letter case. m (multiline) makes ^ and $ match the start and end of each line instead of only the whole string. s (dotAll) makes . match newline characters too, which it normally doesn't. u (Unicode) treats the pattern as a sequence of Unicode code points rather than UTF-16 code units, required for correctly matching characters outside the Basic Multilingual Plane like many emoji.
| Flag | Name | Effect |
|---|---|---|
| g | Global | Finds all matches, not just the first |
| i | Case insensitive | Ignores letter case |
| m | Multiline | ^ and $ match the start/end of each line |
| s | DotAll | . matches newline characters too |
| u | Unicode | Treats the pattern as Unicode code points |
Capture Groups, Named Groups, and Backreferences
Parentheses ( ) in a pattern create a capture group, a substring within the overall match extracted separately, shown as a numbered entry for each match in this tool. (?: ) creates a non-capturing group, useful for applying a quantifier to a sequence without extracting it. Named capture groups javascript regex syntax looks like (?<name> ), retrievable by name instead of numeric position, and this tool displays each one directly under its match. A backreference (\1, \2, or \k<name>) refers back to a previous capture group's matched text within the same pattern, commonly used in find-and-replace operations. The lookahead vs lookbehind distinction trips up a lot of developers too: (?=...) is a positive lookahead, matching only if followed by the given pattern, without consuming it, (?!...) is a negative lookahead, (?<=...) is a positive lookbehind, matching only if preceded by the given pattern, and (?<!...) is a negative lookbehind. None of the four consume characters themselves; they only assert what does or doesn't come immediately before or after a position, which is exactly why they never show up as part of the matched text itself.
Greedy vs. Lazy Quantifiers
The difference between greedy and lazy regex is the single most common source of "why did my pattern match too much" bugs. *, +, and {n,m} are greedy by default, matching as much as possible before backtracking to satisfy the rest of the pattern. Adding ? after any of them (*?, +?, {n,m}?) makes them lazy, matching as little as possible instead. A classic example: ".*" against text with multiple quoted sections greedily matches from the first quote all the way to the last one, while ".*?" lazily stops at the nearest closing quote.
Why Your Regex Isn't Matching (and Catastrophic Backtracking)
Regex not matching why is one of the most common searches for a reason: it's almost always one of a small number of causes. An unescaped special character (., *, +, (, ), [, ]) being read as regex syntax instead of a literal. A missing flag, usually i for case sensitivity. Or ^/$ not behaving as expected because the m flag isn't set. Separately, catastrophic backtracking is a performance failure, not a matching failure: certain ambiguous, nested quantifier shapes like (a+)+ cause matching time to grow exponentially with input length, which can hang a browser tab or a server process. The fix for catastrophic backtracking is almost always restructuring the pattern to remove the ambiguity between nested quantifiers; this tool's built-in issue detector flags known catastrophic-backtracking shapes before you test against large input. This tool tests JavaScript's RegExp engine specifically, not PCRE (used by PHP and, by inheritance, many other languages), which supports possessive quantifiers and recursive patterns JavaScript's engine doesn't have. A pattern that works here will behave identically in any modern browser or Node.js, but syntax written for a different regex engine may not port over directly. Nothing typed here, pattern or test text, is uploaded; matching runs entirely client-side.