Regex Tester

About the tool: testing regular expressions

A regular expression rarely comes out right the first time, and checking it inside your code takes a while. This tool shows the matches as you type: it highlights what it found in the text, breaks every match down into groups and can show the result of a replacement. There are no third-party ads and no sign-up.

Everything runs in your browser — neither the expression nor the text is sent to a server.

Key benefits of the tool:

• A runaway pattern will not freeze the page: the search runs in a separate thread with a time limit. This is rare among online testers, and the problem is very real — we explain why below.

• Groups are listed separately: under every match you see the numbered and named groups, so it is immediately clear what will end up in $1 or $<name>.

• A replace mode: the switch shows not the matches but the finished result — that makes it easier to build an expression for a bulk edit.

Flags

• g — find every match rather than only the first. Without it the tool shows a single hit.

• i — ignore the case of letters.

• m — multiline mode: ^ and $ start meaning the beginning and the end of each line rather than of the whole text.

• s — the dot starts matching the newline character as well.

• u — proper handling of unicode. Needed when the expression contains \p{...} or characters outside basic Latin.

• y — sticky search: the match has to start exactly at the current position.

Why a bad pattern can hang the browser

It is called catastrophic backtracking. When an expression has nested repetition, as in (a+)+$, the engine tries every possible way of splitting the string. The number of variants doubles with each character, so at three dozen letters the computation already lasts longer than you are prepared to wait.

In an ordinary tester such an expression freezes the tab for good, and only closing it helps: a regex already running cannot be stopped. That is why the search here is moved into a separate thread, and if it does not finish within a second and a half, the thread is simply stopped and you see a warning instead of a freeze.

The practical lesson reaches beyond this tool: if a regular expression processes data that arrives from outside, nested repetition is worth avoiding. Otherwise it is not merely an inconvenience but a way to take a server down with a single line.

A few practical tips

• Start small: build the expression for one case, then widen it, checking against the list of matches each time.

• Prefer something narrower than the dot: [^,]+ works faster and more predictably than .+, and causes catastrophic backtracking far less often.

• Named groups read better: (?<year>\d{4}) is clearer in code than $1, especially when there are several groups.

• Do not parse HTML with regular expressions: nested tags cannot be described by a regular expression in principle. There are parsers for that.