All processing runs in your browser — no files or inputs are uploaded to a server.
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.
pattern: \b([\w.+-]+)@([\w-]+\.[\w.-]+)\b flags: gi text: Contact alice@example.com or BOB@test.org. Also: charlie@nope, dave@work.io.
3 matches #1 alice@example.com group1=alice group2=example.com #2 BOB@test.org group1=BOB group2=test.org #3 dave@work.io group1=dave group2=work.io
The g flag returns every match instead of stopping at the first; i makes the match case-insensitive. "charlie@nope" is skipped because there is no dot after the host.
pattern: (?<y>\d{4})-(?<m>\d{2})-(?<d>\d{2}) flags: g
text: started 2024-01-15, deployed 2024-06-30, retired 2025-01-013 matches #1 2024-01-15 y=2024 m=01 d=15 #2 2024-06-30 y=2024 m=06 d=30 #3 2025-01-01 y=2025 m=01 d=01
Named groups (?<name>...) are easier to read than numbered ones — and in real code you can access them as match.groups.y instead of match[1].
pattern: ^ERROR.* flags: gm text: INFO starting ERROR file not found WARN retrying ERROR timeout
2 matches #1 ERROR file not found #2 ERROR timeout
Without m, ^ matches only the very start of the input. With m, ^ matches the start of every line, which is what you usually want for log scraping.
pattern: <pre>(.*?)</pre> flags: gs text: <pre>line one line two</pre> trailing
1 match #1 <pre>line one\nline two</pre> group1=line one\nline two
Normally . does not match newlines. The s flag makes . cover everything including \n, which is what you want when capturing across line breaks. The ? after .* keeps the match non-greedy so it stops at the first </pre>.
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.
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.
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.
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.
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.
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.
Format and validate JSON. Indented or minified output, with clear error messages.
Encode text to Base64 or decode Base64 back to text. UTF-8 safe.
Percent-encode or decode URL components.
Decode JWT header and payload locally. Signature is not verified — paste tokens at your discretion.
Contact alice@example.com or BOB@test.org. Also: charlie@nope, dave@work.io.
JavaScript flavor (ECMAScript). Differs from PCRE / Python in some edge cases.