Regex Tester

A regular expression is a program, and like any program it needs testing before deployment. That is exactly what a regex tester is for. The difference is that regex bugs are unusually silent: a pattern that matches slightly too much or slightly too little produces plausible-looking output that is quietly wrong. A regex tester with live highlighting turns that silent failure into something you can see on every keystroke.

This online regex tester runs JavaScript-flavoured patterns against your own sample text: matches highlight as you type, capture groups break out with their exact spans, a replacement preview shows the substituted output before you commit it, and a step budget guards against the catastrophic backtracking that freezes lesser tools.

Building a regex pattern deliberately

The reliable method is incremental. Start with a literal substring that appears in a real match. Widen it one character class at a time, checking the highlight after each change. When it matches everything you want, add anchors and boundaries to exclude what you do not want. Writing a full pattern from memory and then debugging it is far slower than growing one that works.

The regex flags that matter most

g — global. Without it, most languages return only the first match. With it, they return all. Forgetting g in a replace operation is the classic "it only fixed the first one" bug.

i — case-insensitive. Useful for user-facing text. Dangerous for identifiers, where case carries meaning.

m — multiline. Redefines ^ and $ as line boundaries. Essential when processing a document line by line with a single pattern.

s — dotAll. Lets . match \n. Without it, .* stops at the end of a line, which surprises almost everyone the first time.

u — Unicode. Enables \p{...} property escapes and correct surrogate-pair handling. Use it whenever the input may contain emoji or non-BMP characters.

Character classes worth memorising

Each has an uppercase negation: \D, \W, \S.

Greediness is the default in regular expressions

Quantifiers are greedy. <.+> applied to <a><b> matches the entire string, because + consumes everything it can and only backtracks as far as necessary to satisfy the final >. If you wanted each tag separately, you need <.+?>.

The mental model: greedy means "take as much as possible, then give back until it works". Lazy means "take as little as possible, then take more until it works". Both arrive at a match; they arrive at different ones.

Lookaround in regular expressions

• (?=...) positive lookahead — what follows must match, but is not consumed.
• (?!...) negative lookahead — what follows must not match.
• (?<=...) positive lookbehind — what precedes must match.
• (?<!...) negative lookbehind — what precedes must not match.

Lookaround is the tool for matching a position based on context: a password containing a digit without consuming it, a price not preceded by a currency symbol, a word not followed by a comma.

Performance and catastrophic backtracking

Backtracking engines explore alternatives, and nested quantifiers multiply them. (a+)+b against aaaaaaaaaaaaaaaaac takes exponential time because the engine tries every possible way to partition the a's before concluding failure. If a pattern hangs on a non-matching input, that is what is happening. Restructure to remove the ambiguity, or use an engine with atomic groups or possessive quantifiers.

Testing a regex replacement before you ship it

A replacement is a second program riding on the first, and it deserves the same testing. $1, $<name> and $$ all behave differently across engines, and a pattern that captured correctly can still produce a mangled substitution when the replacement references a group that did not participate in the match. The replacement preview in this regex tester shows the final output against your real sample text, so the difference between what you meant and what you wrote is visible before it reaches a codebase. Test the pattern, then test the replacement, then ship.

A regex checker that keeps up as you type

Feedback speed is the whole value of an online regex tester. Every keystroke re-runs the pattern against the full sample and re-highlights the matches, so widening a character class or tightening an anchor shows its effect immediately rather than after a batch run over production data. When a pattern is slow, the step budget reports it instead of hanging the tab — which is also a useful warning about how that pattern will behave on a much larger input in the real system.

Common patterns people test here

• Emails, URLs and slugs — the classics, always slightly wrong on the first attempt.
• Date and number formats — capture groups for day, month and year, or thousands separators.
• Log line parsing — extracting timestamps, severity levels and message bodies from raw logs.
• Password rules — lookaheads asserting digit, upper-case and symbol requirements at once.
• Search and replace at scale — verifying a substitution before running it over hundreds of files.

Each of these is faster to build incrementally in a regex tester than to write blind and debug from the results of a failed run.