Regular Expression Tester
Test and debug regular expressions with instant pattern matching and replacement.
Exactly Which Regex Flavor and Flags This Tool Runs
This tester compiles your pattern with JavaScript's native RegExp engine (ECMAScript regex), not PCRE, .NET, or Python's re module — and the differences are real, not academic. JavaScript has no possessive quantifiers (a++) or atomic groups, and historically lacked lookbehind support (modern engines now support (?<=...) and (?<!...), but older browsers may not). If you're porting a pattern written for Python or PCRE, watch especially for inline flags like (?i) — JavaScript doesn't support those; flags must be set via the checkboxes below or the RegExp constructor, never embedded in the pattern text itself.
The checkboxes here expose exactly four of JavaScript's six regex flags: g (global), i (case-insensitive), m (multiline), and s (dotall). There's no checkbox for u (unicode mode, needed for correctly matching astral-plane characters and \u{...} Unicode property escapes like \p{Emoji}) or y (sticky mode). If your pattern relies on Unicode property escapes or needs to match starting at a specific lastIndex without scanning forward, this tool can't set the flags required — those patterns will need testing elsewhere or via your own script with the u flag explicitly added.
Two Gotchas Specific to This Tool's Behavior
Without the "g" flag, "Test" only shows you the first match
If your test string clearly contains three matches but the results panel only shows one, check whether Global (g) is checked. Unchecked, the tester (correctly, matching JavaScript's own exec() behavior) stops at the first match rather than scanning the whole string — this trips people up constantly, including experienced developers who forget the checkbox rather than the regex being wrong.
You can't test "replace with nothing" (deleting a match)
This tool's "Replace" button requires non-empty text in the Replacement field and throws "Replacement string is empty" if you leave it blank — so if your goal is to test removing matched text (a genuinely common regex use case, e.g. stripping whitespace or comments), leaving the field empty as you'd do in a real .replace(regex, "") call won't work here. Workaround: type a placeholder, confirm which text matched via "Test" first, then apply the empty-string replacement in your actual code.
Regular Expression Basics
Common Metacharacters
.- Matches any single character (except newline)*- 0 or more of preceding element+- 1 or more of preceding element?- 0 or 1 of preceding element^- Start of string/line$- End of string/line
Character Classes
\d- Any digit (0-9)\w- Any word character (a-z, A-Z, 0-9, _)\s- Any whitespace character[...]- Character class (e.g., [a-z])()- Capture group|- Alternation (OR)
Understanding Regex Flags
🔍 Global Flag (g)
Matches all occurrences in the string instead of stopping at the first match. Essential for find-all operations.
Aa Case Insensitive Flag (i)
Matches without distinguishing between uppercase and lowercase letters. Useful for case-agnostic searches.
⬇️ Multiline Flag (m)
Treats ^ and $ as line boundaries instead of string boundaries. Important for multi-line text processing.
⊙ Dotall Flag (s)
Makes . match newline characters in addition to any other character. Used for matching across lines.
Advanced Regex Techniques
Capture Groups & Backreferences
Use parentheses to create capture groups: (\d{3})-(\d{3})-(\d{4}). Reference them in replacements with $1, $2, $3
Quantifiers & Ranges
Specify how many times to match: a{3} (exactly 3), a{2,4} (2 to 4), a{2,} (2 or more)
Lookahead & Lookbehind
Use assertions to match without consuming characters: (?=pattern) positive lookahead, (?!pattern) negative lookahead
Non-Capturing Groups
Create groups that don't capture: (?:pattern). Useful for grouping without creating backreferences
Common Regex Patterns
Email Validation
/^[^\s@]+@[^\s@]+\.[^\s@]+$/
URL Validation
/^https?:\/\/.+/i
Phone Number (US)
/^\(?\d{3}\)?[\s.-]?\d{3}[\s.-]?\d{4}$/
IP Address
/^(\d{1,3}\.){3}\d{1,3}$/
Greedy Matching and Escaping — Where Patterns Usually Go Wrong
Quantifiers (*, +, {n,m}) are greedy by default — they consume as much as possible and only backtrack if the rest of the pattern fails to match. This is the single most common source of "my regex matched too much" bugs: a pattern like <.+> against <b>bold</b> greedily matches the entire string from the first < to the last >, not just <b>. Add a ? after the quantifier (<.+?>) to make it lazy — matching as little as possible instead. Paste both versions into the tester against the same string with the "g" flag on and compare the match count and boundaries; the difference is immediately visible.
Twelve characters carry special meaning in JavaScript regex and must be escaped with a backslash to match them literally: . * + ? ^ $ { } ( ) | [ ] and \ itself. A very common real bug is an unescaped literal dot in something like a version number or IP-shaped pattern — 192.168.1.1 written without escaping the dots will also match 192x168x1x1, because an unescaped . matches any character, not just a literal period.
Frequently Asked Questions
Why did "Test" only return one match when I expected several?
Check the Global (g) checkbox — without it, this tool (matching real JavaScript exec() semantics) stops after the first match instead of scanning the rest of the string.
Why won't "Replace" let me delete matched text?
The Replacement field must be non-empty or the tool throws an error — it can't currently simulate .replace(regex, ""). Confirm your matches with "Test" first, then apply the empty-string replacement in your actual code, not in this tool.
A pattern that works in Python doesn't work here — why?
This tester runs JavaScript's regex engine, not Python's. Common culprits: inline flags like (?i) aren't supported in JS (use the checkboxes instead), and named groups use (?<name>...) in both, but Python's \g<name> backreference syntax in replacements has no JS equivalent — JS replacement strings use $<name> instead.
Can I test Unicode property escapes like \p{Emoji}?
Not reliably here — those require the u flag, which this tool's checkboxes don't expose. You'd need to test that pattern with your own script or a tool that lets you set the unicode flag explicitly.
My pattern matches more text than I expect — how do I fix it?
You're likely hitting greedy quantifier behavior. Try making the quantifier lazy (add a ? after it, e.g. .+?) or tighten the character class so it can't cross the boundary you don't want it to cross.