Regex Tester

How to Use the Regex Tester

1. Type your pattern into the Pattern field without surrounding slashes. For example, enter \\b\\d{3}-\\d{4}\\b, not /\\b\\d{3}-\\d{4}\\b/g.
2. Toggle the flags you need from the checkbox row: g for all matches, i for case-insensitive, m for multiline anchors, s for dot-matches-newline, u for Unicode, y for sticky.
3. Paste your test text into the large Subject area. The highlighter runs on every keystroke so you get immediate feedback.
4. Inspect the match list below the textarea. Each entry shows the match index, the matched substring, and any numbered or named capture groups.
5. Open the cheat sheet if you need a reminder of quantifier syntax, anchors, character classes, or lookaround constructs.
6. Copy a pattern using the copy button if you want to drop it into your code as a literal or new RegExp().

Under the Hood

Your pattern is compiled via new RegExp(pattern, flags), which hands it to the same engine your JavaScript code uses at runtime - V8's Irregexp in Chrome and Node, SpiderMonkey's regexp engine in Firefox, or JavaScriptCore's YARR in Safari. When you type, a try/catch block catches SyntaxError and shows it inline instead of throwing. Matching uses String.prototype.matchAll so you get the full list of matches together with groups, indexes, and input length without having to run the regex in a loop. The highlighter walks the match array once and splices <mark> spans into the DOM via a safe text-node approach, so special characters in your subject are never treated as HTML.

When You Would Use It

• Prototyping a validation pattern for an email, phone, or invoice number before you paste it into your Zod, Joi, or Yup schema.
• Debugging a regex that works in your IDE but behaves differently in production because of a subtle flag mismatch.
• Extracting structured data from log lines - timestamps, IPs, request IDs - and verifying the capture groups land where you expect.
• Teaching someone the difference between greedy and lazy quantifiers by toggling .* versus .*? over the same input.
• Converting a grep -E command into a JavaScript regex and confirming the semantics survive the translation.

Common Pitfalls and Edge Cases

• ECMAScript is not PCRE. Patterns that rely on possessive quantifiers, subroutine calls, or conditional groups will not compile; these come from PCRE/Perl and have no ECMAScript equivalent.
• Lookbehind support. Variable-length lookbehind like (?<=foo.*) is supported in modern V8, SpiderMonkey, and JavaScriptCore, but fails in older Safari builds. If you target pre-2020 browsers, avoid it.
• Unicode property escapes such as \\p{L} only work when the u flag is set. Forgetting it produces an invalid-escape error.
• Surrogate pairs. Without the u flag a single emoji is two code units and . only matches the first half.
• The global flag and lastIndex. Reusing the same RegExp object with g and .test() advances lastIndex between calls, which is a classic source of "why does my validator alternate true/false" bugs.
• Catastrophic backtracking. Patterns like (a+)+$ against a long non-matching input can freeze the tab. If the highlighter hangs, your pattern is almost certainly quadratic or worse.

Regex Syntax Background

The ECMAScript regular expression grammar is specified in Annex B and section 22.2 of the ECMA-262 standard. It draws heavily from Perl and PCRE but diverges in places: no embedded modifiers with (?i), no named atomic groups, limited Unicode support without the u flag, and distinct semantics for $ at the end of a string when m is off. Other regex flavors in common use include PCRE (PHP, nginx), Python's re and regex modules, Go's RE2 (linear time, no backtracking), and POSIX ERE as implemented by grep -E. RE2 deserves special mention: it rejects backreferences and lookaround but guarantees linear-time matching, which is why Google uses it for user-supplied patterns.

Comparison to Alternatives

For complex test suites that need to be version-controlled with your codebase, regex101.com offers permalinks and a per-pattern debugger that steps through each token - extremely useful when you are truly stuck. grep -P, ripgrep, and sed -E remain the fastest way to search a large code base from the terminal, and ripgrep's Rust regex engine is PCRE-compatible but runs in guaranteed linear time. Your IDE's Find-in-files is perfect when you want to couple a regex with context and replace across many files. Use this web tester when you need to nail down one ECMAScript-specific pattern, avoid installing anything, and see per-match capture groups at a glance - especially because the engine here is exactly the one your Node.js service or browser code will use.