Regex Tester

Greedy, lazy, and why your pattern grabbed too much

By default every quantifier is greedy: it takes as much as it can and gives characters back only when the rest of the pattern cannot otherwise match. This is behind the most common surprise in regular expressions. Run the pattern <.+> against the text <b>bold</b> and you get one match spanning the entire string, not the two tags you expected, because .+ swallowed everything up to the final angle bracket before backing off.

Adding a question mark after the quantifier makes it lazy - it takes as little as possible and grows only when forced. <.+?> against the same input matches <b> and </b> separately. The breakdown panel on this page labels lazy quantifiers explicitly, because a single question mark buried in a long pattern is easy to miss when you are reading someone else's work.

The other frequent surprise is that a dot does not match a line break unless you set the dot-all flag. A pattern that works perfectly on one line and mysteriously fails across two is almost always this.

Catastrophic backtracking, and why this tool uses a background thread

JavaScript's regex engine is a backtracking engine. When a match fails it does not give up; it returns to the last point where it had a choice and tries the other branch. Usually that is cheap. With nested quantifiers it is not, because the number of ways to divide the input between the inner and outer quantifier grows exponentially with its length.

The canonical example is (a+)+$ tested against a string of a characters that ends in something else. Measured while building this tool, on the same JavaScript engine Chrome uses, that pattern against just 31 characters ran for 61 seconds - over a minute of solid computation for an input you could type by hand. Doubling the input roughly doubles the exponent, so 40 characters is hours.

This matters beyond curiosity. A regular expression that runs on user-supplied input in a web server is a denial-of-service vector, and it has a name: ReDoS. A single crafted request can pin a CPU core for minutes. It is worth checking any pattern you plan to run on untrusted input for nested quantifiers before it ships.

It is also why this page evaluates your pattern in a Web Worker rather than on the page's main thread. A regular expression in the middle of backtracking cannot be interrupted - it ignores timers, events, and every other signal, so a tab that starts one simply stops responding until it finishes. Running it on a separate thread means it can be killed. If a pattern here takes longer than one second, the thread is terminated and you get a message instead of a frozen page.

Capture groups: numbered, named, and non-capturing

Round brackets do two jobs at once. They group part of a pattern so a quantifier or an alternation applies to the whole thing, and they capture whatever matched inside them for later use. Groups are numbered from one, left to right, by the position of their opening bracket - which is why adding a bracket early in a pattern silently renumbers everything after it and quietly breaks the replacement string you wrote last week.

Named groups fix that. Writing (?<year>[0-9]{4}) lets you refer to the capture as year rather than as $1, in both the match results and the replacement. The name survives edits elsewhere in the pattern, so it is the better choice in anything you intend to keep.

When you want grouping without capture, use (?: at the start of the group. It keeps the numbering of your real groups stable and tells the next reader that nothing inside is meant to be extracted. This page labels each bracket by kind, so you can see at a glance which groups are capturing and what number each one holds.

What the flags actually change

The global flag is the one with the most confusing effects, because it changes behaviour rather than just breadth. With it, a replacement rewrites every match; without it, only the first, which is the engine's rule and not a limitation of any particular tool. It also means the regex object keeps a position between calls, which is a classic source of bugs when the same regex object is reused in a loop.

Multiline changes the meaning of the anchors: ^ and $ stop meaning start and end of the whole input and start meaning start and end of each line. Sticky goes further and requires the match to begin exactly at the current position rather than searching forward, which is what makes it useful for writing tokenisers.

The unicode flag makes the pattern operate on code points rather than UTF-16 code units, and it is required before \p{...} property escapes such as \p{Lu} will work at all. Without it, that syntax either throws or means something else entirely.