Regex Tester

Test regular expressions against sample text with live highlighting and capture group details.

/ /

Testing patterns before you ship them

Regular expressions are dense, easy to get subtly wrong, and painful to debug once embedded in code. A pattern that looks correct often matches slightly more or slightly less than intended, and the failure only surfaces on unusual input. Testing against real sample data before the pattern goes anywhere near production saves a great deal of time.

This tester highlights every match directly in your test string as you type, counts them, and breaks out each capture group so you can see exactly what the pattern extracted.

The flags and what they change

The g flag makes the pattern find every match rather than stopping at the first. Without it, a search returns one result no matter how many exist. The i flag makes matching case-insensitive, so a pattern for "error" also matches "Error" and "ERROR".

The m flag changes the meaning of the anchors. Normally the caret matches the start of the whole string and the dollar sign matches the end. With multiline enabled, they match the start and end of each line instead, which is what you usually want when processing log files or lists.

The s flag, sometimes called dotall, lets the dot match newline characters. By default a dot matches any character except a line break, which is why patterns spanning multiple lines fail unexpectedly.

Capture groups

Parentheses create a capture group, and the text each group matched is shown separately in the results. This is how you extract parts of a match rather than the whole thing — pulling the year out of a date, or the domain out of an email address.

Named groups, written with the syntax placing a name in angle brackets after the opening parenthesis, make patterns considerably more readable. Referring to a captured year by name rather than by position is easier to maintain when the pattern later changes.

Common mistakes

Forgetting to escape special characters is the most frequent error. A literal dot must be written as an escaped dot, otherwise it matches any character. The same applies to plus signs, question marks, parentheses and square brackets.

Greedy quantifiers cause the second most common problem. By default a quantifier matches as much as possible, so a pattern intended to capture one HTML tag will happily swallow everything up to the last closing bracket in the document. Adding a question mark after the quantifier makes it lazy, matching as little as possible instead.

Runs locally

Patterns and test data are evaluated by your browser's own regular expression engine. Nothing is transmitted, which matters when your test data is a sample of real log output or customer records.

Frequently Asked Questions

Which regex flavour does this use?

JavaScript's built-in engine, which follows the ECMAScript specification. Most syntax is shared with other languages, though lookbehind support and some Unicode features differ from PCRE.

Why does my pattern only find one match?

The global flag is probably off. Without g, matching stops at the first result.

What is the difference between greedy and lazy quantifiers?

Greedy quantifiers match as much as possible; adding a question mark makes them lazy so they match as little as possible. Greedy matching is the usual cause of a pattern capturing far more than intended.

How do I match a literal dot?

Escape it with a backslash. An unescaped dot matches any single character, which is rarely what you want when parsing something like a filename.

Is my test data sent to a server?

No. Everything is evaluated in your browser, so you can safely test against real log samples or customer data.