Regex tester for JavaScript.

The pattern you type is compiled with new RegExp(pattern, flags) by your browser's JavaScript engine and run against your test text on every change. The same engine family powers Node.js, Deno, Bun and front-end code, so a pattern that behaves here behaves the same in your JavaScript or TypeScript project.

Every match is highlighted in place, up to 500 matches. Zero-length matches, such as those from ^ or \b, show as a thin marker and the tester steps past them so a pattern like a* never loops forever. If the pattern has groups, a table lists the full match and each group for the first 50 matches, with named groups labelled by name. When the pattern is invalid, you see the engine's own error message, the same one your code would throw.

Because you type the pattern without surrounding slashes, you do not need to escape forward slashes here. Inside a JavaScript regex literal such as /https?:\/\// you do.

g (global) finds every match instead of stopping at the first. i ignores case. m (multiline) makes ^ and $ match at the start and end of each line instead of only the whole string. s (dotAll) lets . match line breaks, which it otherwise never does.

u (unicode) treats the pattern and text as Unicode code points, so an emoji counts as one character, and it enables property escapes such as \p{L} for any letter or \p{Script=Devanagari}. It also makes the syntax stricter, turning some silent mistakes into errors. y (sticky) only matches at the exact position where the previous match ended, which is useful for tokenisers.

JavaScript also has d (match indices) and v (an upgraded Unicode mode with set operations in character classes). They are not toggles in this tester, so test patterns that need them in your own runtime.

Most everyday syntax is shared across flavours: character classes, quantifiers, groups, alternation, anchors and lookahead. The differences show up at the edges.

JavaScript has no possessive quantifiers, no recursion and no \A or \Z anchors (use ^ and $ without the m flag). A leading (?i) mode switch from PCRE is a syntax error; use the i flag instead. Named groups are written (?<name>...), where Python's re module uses (?P<name>...). JavaScript allows variable-length lookbehind, which Python's re rejects.

Shorthand classes differ too. In JavaScript, \d means only 0-9 and \w only ASCII letters, digits and underscore, even with the u flag. Python 3 matches Unicode digits and letters with \d and \w by default. If you validate names or numbers in languages other than English, test with real data, and use \p{...} escapes when you mean "any letter".

If your target is PHP (preg_*), Python or Go, use this tester for the shared core and check advanced features against that engine's documentation. For typed front-end code, see TypeScript vs JavaScript.

Parentheses capture: (\d{4}) stores the year so you can read it as group 1. Non-capturing groups (?:...) group without storing, which keeps the group numbers tidy. Named groups (?<year>\d{4}) are still numbered in order, and the table shows both the number and the name.

Backreferences reuse what a group matched: (\w)\1 finds doubled letters, and \k<name> does the same for a named group. An optional group that did not take part in a match shows as undefined in the table, which is what match[n] returns in code.

Lookarounds test without consuming text. (?=...) and (?!...) look ahead, (?<=...) and (?<!...) look behind. Lookbehind is supported in all current major browsers and Node.js. A common use is checking several rules at once, such as a password that must contain a digit and an uppercase letter.

An unescaped dot matches any character, so example.com also matches exampleXcom. Escape it as \. when you mean a literal dot. The same goes for +, ?, *, (, ), [, {, | and ^ outside a character class.

Greedy quantifiers take as much as they can: <.+> on "<b>bold</b>" matches the whole string. Add ? to make them lazy (<.+?>), or use a negated class such as <[^>]+>, which is usually clearer and faster.

Forgetting anchors lets a validation pattern match part of the input: \d{4} accepts "abc12345". Use ^ and $ to match the whole value. And when you move a pattern into a JavaScript string for new RegExp, double every backslash: "\\d+" in the string becomes \d+ in the regex. That single detail explains most "works in the tester, fails in my code" reports.

Finally, regex is the wrong tool for nested formats such as HTML or JSON. Use a parser for those and keep regex for flat patterns, which is how most web scraping pipelines combine the two.

JavaScript uses a backtracking engine. Patterns with nested or overlapping quantifiers, such as (a+)+$ or (\w+\s?)*$, can take exponential time on an input that almost matches. On a server this is a denial-of-service risk known as ReDoS, and it sits squarely in the injection and availability concerns covered by our OWASP Top 10 checklist.

This tester runs on your browser's main thread, so a catastrophic pattern can freeze the tab for a while, just as it would freeze your app. That makes it a useful test bench: try long near-miss strings before shipping any regex that runs on user input. Prefer specific character classes, avoid nesting quantifiers, anchor patterns, cap input length, and let static code analysis tools flag risky patterns in review.