Skip to content
Advertisement

Regex Tester

Test a JavaScript regular expression live — highlighted matches, capture groups, a replace preview, and a library of common patterns.

Text Reference

flags: gi

Flags

Common patterns

111 chars

Output view
Matches
2 first at index 5
Capture groups
2
Test string
111 chars 2 lines

Highlighted matches

Ping ada.lovelace+work@example.co.uk or support@swiss-knives.app. not-an-email@ and @nope.com should not match.

Every match with its position and capture groups
# Range Match Groups
1 5–36 ada.lovelace+work@example.co.uk
  • userada.lovelace+work
  • domainexample.co.uk
2 40–64 support@swiss-knives.app
  • usersupport
  • domainswiss-knives.app

JavaScript flavor

Patterns run on your browser's own RegExp engine, so the syntax is ECMAScript — not PCRE. Lookbehind, named groups (?<name>…), backreferences \k<name> and Unicode property escapes (with the u flag) all work; atomic groups, possessive quantifiers and recursion do not. Nothing you type is uploaded.

How Regex Tester works

A regular expression is a pattern compiled into a state machine that scans your input for matches. JavaScript’s engine is backtracking-based: when a quantifier can match several ways, it tries one and returns to try another if the rest of the pattern fails. That flexibility is what makes lookahead and backreferences possible, and also what makes some patterns pathologically slow.

Flags change the whole match. The g flag finds every match rather than the first; i makes matching case-insensitive; m makes ^ and $ match at line boundaries instead of only at the start and end of the input; s lets . match newlines; and u enables full Unicode handling, which matters as soon as your input contains emoji or characters outside the Basic Multilingual Plane.

Capture groups are the other half of the tool. Parentheses record what they matched so you can extract it, and named groups — (?<year>\d{4}) — make both the pattern and the replacement readable. Non-capturing groups (?:…) let you apply a quantifier to a sub-pattern without paying to record it.

Replacement uses $1, $2, or $<name> to refer to captures, $& for the whole match, and $$ for a literal dollar sign. Previewing the replacement against real input is the fastest way to catch a pattern that matches more than you intended.

Reference

  • Quantifiers: * (0+) + (1+) ? (0 or 1) {n} {n,} {n,m} — append ? for lazy matching
  • Classes: \d digit \w word character \s whitespace . any character except newline
  • Anchors: ^ start $ end \b word boundary
  • Groups: (…) capture (?:…) non-capturing (?<name>…) named
  • Lookaround: (?=…) ahead (?!…) negative ahead (?<=…) behind (?<!…) negative behind

How to use this tester

  1. Write the pattern

    Type your expression, or start from one of the built-in presets for emails, URLs, dates, and other common shapes.

  2. Set the flags

    Enable g to find every match, i for case-insensitivity, m for multi-line anchors, and u when Unicode is involved.

  3. Paste test input

    Matches are highlighted live as you type, with each capture group broken out separately.

  4. Preview a replacement

    Enter a replacement string using $1 or $<name> to confirm the substitution does what you expect before you ship it.

Worked examples

Greedy versus lazy

Given
Pattern <.+> and <.+?> against "<a><b>"
Result
Greedy matches "<a><b>"; lazy matches "<a>"

The greedy quantifier consumes as much as possible and backtracks only as far as it must. Adding ? makes it stop at the first workable point.

Named groups in a replacement

Given
(?<day>\d{2})/(?<month>\d{2})/(?<year>\d{4}) replaced with $<year>-$<month>-$<day>
Result
25/12/2026 → 2026-12-25

Named groups survive a pattern edit that renumbers the positional ones, which is why they are worth the extra characters.

Catastrophic backtracking

Given
Pattern (a+)+$ against a long string of a characters ending in b
Result
The engine explores exponentially many paths and hangs

Nested quantifiers over overlapping alternatives are the danger sign. This is a real denial-of-service vector when the pattern runs on user input.

When to use it

  • Building and debugging a validation pattern before dropping it into your application.
  • Extracting fields from log lines or semi-structured text with capture groups.
  • Testing a find-and-replace across a sample before running it over a whole repository.
  • Understanding an unfamiliar regex inherited from an existing codebase.
  • Checking that a pattern behaves correctly on Unicode input, not just ASCII.

Things to watch out for

  • Regular expressions cannot parse nested structures. HTML, JSON, and source code need a real parser; a regex will always be defeated by nesting.
  • Watch for catastrophic backtracking. Nested quantifiers over overlapping patterns can take exponential time and are a genuine denial-of-service risk on user-supplied input.
  • Do not validate email addresses with an exhaustive regex. RFC 5322 permits far more than most patterns allow — check for an @ with something either side, then send a confirmation message.
  • JavaScript regex syntax differs from PCRE, Python, and Go in places. A pattern copied from another language may compile and behave differently.

Frequently asked questions

What is the difference between greedy and lazy quantifiers?

Greedy quantifiers (* + {n,}) match as much as possible and give characters back only when the rest of the pattern fails. Adding ? makes them lazy: they match as little as possible and expand only when forced. It is the usual reason a pattern captures far more text than intended.

Why does my pattern only find the first match?

The g flag is not set. Without it, methods such as match and replace stop after the first match. With it, they scan the entire input — which also means a stateful regex object carries lastIndex between calls.

Can I parse HTML with a regular expression?

Not reliably. HTML nests arbitrarily deep and regular expressions cannot count nesting. Use a DOM parser. A regex is fine for a narrow, well-known shape in a controlled input, and a source of subtle bugs anywhere else.

What is catastrophic backtracking?

A pattern whose nested quantifiers create exponentially many ways to match. On a non-matching input the engine tries them all, and a few dozen characters can hang the process. Avoid nesting quantifiers over overlapping alternatives, especially in patterns that run on user input.

Is my test data sent anywhere?

No. Patterns and input are evaluated by your browser’s own regex engine. Nothing is transmitted, so testing against real log lines or production samples is safe.

Why does my pattern behave differently in another language?

Regex dialects diverge on lookbehind support, Unicode property escapes, named-group syntax, and the exact meaning of \b and \w. This tester uses the JavaScript engine, so verify separately if the pattern will run in Python, PCRE, or Go.

Related Developers tools

All developer tools