Regex Tester

It runs your browser's engine, and only that

There is no hand-written matcher here. The page hands your pattern to `new RegExp`, the same call your own code makes, and shows you the result. That is a deliberate choice with a specific consequence: what you see is true for JavaScript in this browser today, and it does not transfer.

A pattern that works here may fail in Python, in Go, in a database query, or in the same browser on an older version. The flavours genuinely differ — PCRE has possessive quantifiers and atomic groups, JavaScript did not get lookbehind until 2018, and Python's `re` has no `\p{...}` at all. If you are writing the pattern for something other than a browser, test it there.

Here is a real disagreement between two engines, on the same pattern and the same three characters. It is worth knowing because both answers are correct and neither is a bug:

// JavaScript
[..."aaa".matchAll(/a*?/g)].map(m => m[0])
// ["", "", "", ""]      four

// Python
re.findall(r"a*?", "aaa")
// ['', 'a', '', 'a', '', 'a', '']   seven

The lazy quantifier can match nothing *or* one `a`, and the two engines disagree about whether both are reported at the same position. JavaScript advances past a position once an empty match has been taken; Python tries the longer alternative at the same offset first. A pattern with a lazy quantifier that can also match something real is therefore the case to be most careful about when moving between languages.

The error message is the same story. It is the browser's own text, shown verbatim, and the wording differs between Chromium, SpiderMonkey and JavaScriptCore. When your pattern is rejected, the message you will meet in your own console is the one on this page — which is precisely why it has not been tidied up.

This page adds the g flag, and says so

Without `g`, `RegExp.exec` and `String.match` return exactly one match — the first — and stop. That is correct behaviour, and it is almost never what someone typing into a tester wanted. So this page adds `g` when your pattern does not have it, and marks the status bar with `+g added` rather than quietly changing what you asked for.

const re = /\d+/;          // no g
"a1 b22".match(re)     // ["1"]      one match, and it stopped
"a1 b22".match(/\d+/g) // ["1", "22"]

// exec is the same: lastIndex is only consulted when g is present
const sticky = /\d/g
sticky.exec("a1 b22")  // "1"
sticky.exec("a1 b22")  // "22"

There is a `g` in JavaScript that is not this one: `y`, sticky, which anchors the match to `lastIndex` and gives up at the first miss. It is genuinely useful for tokenising, and it will find far fewer matches than you may expect. This page does not adjust it.

The empty match, which is real and which testers usually hide

A pattern like `a*` can match without consuming anything. The engine finds those, and so does this page — shown as `(empty match)` rather than as a blank cell, which would read as a bug.

[..."aaa".matchAll(/a*/g)].map(m => m[0])
// ["aaa", ""]     greedy: one match takes all three characters, then
//                  one empty match at the position just past the end

[..."aaa".matchAll(/a*?/g)].map(m => m[0])
// ["", "", "", ""]  lazy: an empty match at each of the four positions

Four, not five and not three. A pattern that can match nothing is tried at every position, and a three-character string has four boundaries in it — before the first character, between each pair, and after the last. The greedy form visits two of those because its first match swallows the rest of the text.

If the list ever looks wrong in a way you did not expect, this is the first thing to check: change `*` to `*?` and see whether the count changes. A pattern that can match nothing is also a pattern that can match a very great deal.

A group that did not match is not a group that matched nothing

These two look identical in a table and are not the same thing. A group that took part in the match and captured an empty string is data. A group that did not take part at all — because an alternation went the other way, or an optional group was skipped — is reported here as `no match`, so you can tell which happened.

const re = /(\d)?x/g

re.exec("1xx")   // match "1x", group 1 is "1"
re.exec("1xx")   // match "x",  group 1 is undefined

// A round trip through String(matches) would render both as "" and lose
// the fact that the first one matched a digit and the second did not match
// anything at all.

That distinction matters most with alternations, where it tells you which branch the engine took, and with optional groups, where it tells you the value was genuinely absent rather than present and empty.

Named groups are numbered by when they open

A group containing another group is the outer one first. `(?<outer>(a))` makes `outer` group 1 and the inner group 2, even though the inner one finishes first. This page numbers them the way the engine does, and shows `$1` alongside the name so there is no ambiguity.

/(?=(a))(?<hit>a)/.exec("a")
// 1: "a"     the group inside the lookahead
// 2: "a"     the named group
// groups.hit is group 2, not group 1

/(?=(a))/.exec("a")   // 1: "a"  - the lookahead itself is not a group

The one thing this page cannot protect you from

Some patterns take exponential time on some inputs. This is not a bug in your regex; it is how backtracking works. A greedy quantifier nested inside another one, with a failure at the end, makes the engine try every way of splitting the text before it gives up.

/^(a+)+$/.test("a".repeat(20) + "!")    // instant: fails immediately

This one is not.

// ^(a+)+$ against "aaaaaaaaaaaaaaaaaaaa!"
// tries every way of dividing the a's between the inner and outer
// groups before it can conclude there is no match.
//
// 28 characters:  noticeable
// 32 characters:  seconds
// 36 characters:  minutes

The fix, when a pattern needs to be rewritten, is usually to make the inner quantifier possessive in spirit: replace a nested `(a+)+` with a single `a+` and anchor the whole thing, or replace `.*` between two markers with `[^x]*` so the engine cannot backtrack across the excluded character at all.

The replace preview is the engine's, not this page's

The replacement is applied by `String.prototype.replace` with your own replacement string, so the preview is exactly what your code would produce. That matters because the rules for `$` are sharper than most people expect:

That last row is the one to remember. A pattern with nine groups and a replacement of `$10` does not fail and does not give you a dollar sign and a zero — it gives you the first group's text followed by a `0`. There is a test in this project's suite at both nine and ten groups, because it is exactly the sort of rule that is easy to reimplement slightly wrong.

And there is no escape for a literal dollar other than `$$`. A replacement of `$5.00` is not five dollars; it is group 5 followed by `.00`, or the literal text `$5.00` if there is no group 5.

Offsets count UTF-16 code units

JavaScript string indices are not character positions in the way a text editor counts them. An emoji outside the basic plane is two code units, so everything after it is shifted by two relative to what you would count by hand.

const s = "🎉x"
s.indexOf("x")        // 2, not 1
Array.from(s).length  // 2 - the display length, which is a different question

So the offset this page shows will sometimes disagree with the column your editor reports. Both are right; they are counting different things. The line and column beside each match is derived from the same offset, so it is consistent with the number and not with the editor.

Patterns that work and quietly do not do what you meant

• An unescaped `.` matches any character, so `/api.v1/` also matches `apiXv1`. Write `/api\.v1/`.
• A greedy `.*` between two markers runs to the *last* marker, not the first. `<!--.*-->` over two comments gives you one enormous match. Use `[^]*?` or the `s` flag with `.*?`.
• `^` and `$` match the whole text, not each line, unless `m` is on. This is the single most common reason a pattern that works on one line finds nothing in a file.
• `\b` is a word boundary defined by the `\w` class, so it treats an underscore as a word character. `snake_case_name` is one word to `\b`.
• `\d` is ASCII 0–9 only, even in Unicode mode. Arabic-Indic digits need `\p{Nd}`, which needs the `u` flag.

const text = "<!--a--> keep <!--b--> keep"

text.match(/<!--.*-->/g)
// ["<!--a--> keep <!--b-->"]     one match, the last marker wins

text.match(/<!--[\s\S]*?-->/g)
// ["<!--a-->", "<!--b-->"]       two matches, as intended

What the flags do

`u` and `v` are mutually exclusive and the engine rejects both together. This page swaps one for the other when you tick the second, because a syntax error for a thing the buttons could have made impossible is a poor trade.

Doing it yourself

The built-in is enough. There is no need for a regex library to test a regex, and if you find yourself reaching for one in application code, the more useful question is usually whether the job wants a parser.

re.exec(text)          // first match, or null
re.lastIndex           // where the last one stopped - only moves with g or y
text.match(re)         // array of the full matches, or null
text.matchAll(re)      // iterator of match objects; requires g
text.replace(re, "$1") // substitution, with the engine's $ rules

// Match objects carry more than the text:
const m = /(?<year>\d{4})/.exec("in 2026")
m.index      // 3     where it starts
m[0]         // "2026"  the whole match
m.groups     // { year: "2026" }
m.input      // the whole text it was found in