How to use
Edit the pattern in the top input — no leading or trailing slashes needed, the wrapper shows them for you. Toggle flag chips (g, i, m, s, u, y) to see how each one changes behavior. The test string below highlights every match inline; capture groups and named groups appear in the panel underneath with their position.
The parser is the engine in your browser, so the syntax and behavior match exactly what `new RegExp(...)` would do at runtime. That makes this tool a faithful preview for JavaScript and TypeScript — but a misleading one for Python, Go, Java, or PCRE patterns, which support features (lookbehind variants, possessive quantifiers, atomic groups) that JS does not.
FAQ
Why does my pattern work in Python but not here?
Different flavors. JavaScript regex is close to but not identical to Python's re, Java's java.util.regex, or PCRE. Common gaps: possessive quantifiers (a++), atomic groups ((?>...)), and some Unicode property variants are not supported. Stick to a JS-flavor reference when writing patterns for browser or Node code.
Why does the g flag matter so much?
Without g, regex methods stop at the first match — exec, match, and replace return only one result. With g they iterate through the whole string. Most "why does my regex miss the other matches?" questions come down to a missing g flag.
How do I match Unicode (Korean, Japanese, emoji)?
Enable the u flag to make \w, character classes, and \p{...} Unicode property escapes work correctly. Examples: \p{Script=Hangul} for Korean syllables, \p{Script=Hiragana} for hiragana, \p{Emoji_Presentation} for emoji. Without u these escapes either error or behave unexpectedly.
How can I do a non-greedy match?
Append ? to a quantifier — .*? matches as little as possible, .+? at least one but minimal. Greedy quantifiers (.*, .+) eat as much as they can, which is the cause of most "my regex grabbed too much" bugs when matching delimited blocks.
Can I write a regex to validate email addresses?
Technically yes — RFC 5322 admits a regex — but a strictly correct one is hundreds of characters and still mismatches edge cases. For validation, accept anything with a single @ between two non-empty parts, then send a confirmation email. For extraction (like the email example above), simpler patterns work fine.
Related concepts
A regular expression is a small language for describing patterns in text. The engine reads the pattern, builds a state machine, and walks through the input deciding at each character whether the machine can keep going. Two concepts trip up most beginners. First, greedy vs non-greedy: by default quantifiers grab the longest possible match, which is rarely what you want when matching delimited content like HTML tags or quoted strings. Second, backtracking: when a path fails, the engine rewinds and tries alternatives, and pathological patterns (a+a+b on aaaaaaaac) can blow up to billions of steps. The "regex denial of service" bug class — ReDoS — is exactly this.
JavaScript regex sits in the middle of the flavor landscape. It is more capable than POSIX BRE/ERE but lighter than PCRE. ECMAScript 2018 added lookbehind and named groups; ES2022 added the d flag for match indices; the v flag in ES2024 brings set notation. Coming from another language, the most jarring missing features are usually variable-length lookbehind (limited in JS until recently), possessive quantifiers, and recursive patterns — none of which JS supports natively.
