utoolslib Logo
utoolslib

Regex Tester

Data Stays on Your Device

Test regular expressions against sample text. View all matches and groups.

Common Regex Patterns

Test Text
Loading...
Matches
No matches found.

What is the Regex Tester?

The Regex Tester lets you write a regular expression and see immediately which parts of your test text it matches, including captured groups. It turns pattern writing into a feedback loop instead of guesswork.

A regular expression is a compact description of a text pattern. It is a genuinely powerful tool, and also one where a small syntax change can drastically alter behaviour in ways that are hard to predict by reading alone.

That is why interactive testing matters so much. Seeing highlighted matches against realistic sample text tells you not just whether the pattern works, but where it matches more or less than you intended, the two failure modes that cause bugs in production.

Capture groups are worth particular attention. Parentheses both group parts of a pattern and capture what they matched, and the numbering of those groups determines how you extract values in your code.

How to use the Regex Tester

  1. Enter your pattern. Type the regular expression into the pattern field, without surrounding delimiters.
  2. Set your flags. g matches all occurrences rather than stopping at the first, i makes matching case-insensitive, and m makes ^ and $ match at line boundaries.
  3. Paste representative test text. Include both strings that should match and strings that should not. False positives are as important to catch as false negatives.
  4. Inspect the highlighted matches. Matches are highlighted in the text, with captured groups listed separately for each match.

Worked examples

Extracting dates with capture groups

Each parenthesised section captures a component, which you can then reference by index.

Input
Pattern: (\d{4})-(\d{2})-(\d{2})
Flags:   g
Text:    Released 2024-03-15, updated 2024-11-02.
Output
Match 1: "2024-03-15"
  Group 1: 2024   Group 2: 03   Group 3: 15
Match 2: "2024-11-02"
  Group 1: 2024   Group 2: 11   Group 3: 02

Greedy versus lazy quantifiers

This is the single most common source of confusion. A greedy quantifier consumes as much as it can; adding a question mark makes it lazy and stop at the first opportunity.

Input
Text:    <b>bold</b> and <i>italic</i>

Greedy:  <(.+)>
Lazy:    <(.+?)>
Output
Greedy matches: "<b>bold</b> and <i>italic</i>", one match spanning everything

Lazy matches:   "<b>", "</b>", "<i>", "</i>", four separate matches

Common use cases

  • Building validation patterns. Test a pattern against valid and invalid inputs before wiring it into form validation.
  • Writing log-parsing expressions. Paste real log lines and refine the pattern until it captures the fields you need.
  • Constructing search-and-replace patterns. Verify a pattern here before running a destructive find-and-replace across a codebase.
  • Learning regular expressions. Immediate visual feedback is by far the most effective way to build intuition for how quantifiers and character classes behave.

Features and limitations

  • Live highlighting of matches as you type.
  • Displays numbered and named capture groups per match.
  • Supports the standard JavaScript flags: g, i, m, s, u, and y.
  • Reports syntax errors in the pattern itself, such as unbalanced parentheses.
  • Uses the JavaScript regex engine. PCRE features such as lookbehind in older environments, atomic groups, and recursion may behave differently or be unavailable.

Frequently asked questions

Which regex flavour does this use?

JavaScript's, as implemented by your browser. Most basic syntax is portable, but if you are targeting Python, PCRE, or Go, verify anything unusual in that environment.

What is the difference between greedy and lazy matching?

A greedy quantifier such as .+ matches as much text as possible and then backtracks; a lazy one such as .+? matches as little as possible. Unintended greedy matching is the most frequent cause of a pattern matching far more than expected.

What do the flags mean?

g finds all matches instead of only the first, i ignores case, m makes anchors match at line boundaries, s lets the dot match newlines, u enables full Unicode handling, and y anchors matching at a fixed position.

Why is my pattern extremely slow?

Probably catastrophic backtracking, which happens with nested quantifiers such as (a+)+ against a non-matching string. The engine explores exponentially many paths. Restructuring to avoid nested quantifiers is the fix.

Should I use regex to parse HTML?

Generally no. HTML is not a regular language, and patterns that appear to work fail on nesting, attributes, and comments. Use a real parser. Regex is fine for narrow extraction from text you control.

Is my test data sent anywhere?

No. Matching runs in your browser, so you can safely test patterns against real log excerpts or production samples.

All processing happens locally in your browser, your data never leaves your device.