Regex Tester and Debugger
Regular Expression
Test String
Match Details
No matches yet
Enter a regex and test string
Real-time Matching
See matches instantly as you type. Visual highlighting shows exactly what your regex captures.
100% Private
All processing happens in your browser. No data is ever sent to a server.
Learn Regex
Built-in explanations break down each token. Quick recipes for common patterns.
About the Regex Tester
The Regex Tester evaluates JavaScript regular expressions against test input in real time — capture groups highlighted, match indices reported, replacement preview live. The engine is the same one that ships with V8 and SpiderMonkey, so behavior matches what your `String.prototype.match` and `RegExp.prototype.exec` will do in production. Flags `g`, `i`, `m`, `s`, `u`, and `y` are toggleable; named capture groups, lookbehind, and Unicode property escapes work as defined in the ECMAScript specification. Your pattern and test data stay client-side — the tester never proxies through a server, so you can paste log lines containing PII or secrets without exposure.
Updated: May 8, 2026
Related Tools
How to use the regex tester
- Paste your regex pattern into the pattern field (without surrounding slashes — the input is treated as the body).
- Toggle flags as needed: `g` (global, find all), `i` (case-insensitive), `m` (multiline — `^`/`
toolrunner anchor to line boundaries), `s` (dotall — `.` matches newline), `u` (Unicode mode — required for `\p{L}` escapes), `y` (sticky — match only at lastIndex). - Paste your test string. Matches highlight inline; capture groups appear in the right panel with their index, name (if named), and value.
- Switch to the Replace tab to enter a replacement template; backreferences (`$1`, `$2`, `lt;name>`) and the `amp;` whole-match shortcut work as specified in ECMAScript.
- The match-index column reports the character offset (UTF-16 code units) of each match — useful when porting a pattern to a tool that takes an index input (e.g., a logging pipeline or a code-mod). Note that for strings containing non-BMP characters (like most emoji), the index counts code units, not codepoints.
Common use cases
- Log parsing. Build a pattern that extracts the timestamp, level, and message from your application log format, then export the regex into a logging pipeline (Vector, Fluent Bit, Logstash) or a one-liner `awk` / `sed` command.
- Input validation. Email, URL, phone, postal code, IBAN, credit-card patterns — test edge cases (empty strings, unicode names, IDN domains) before shipping the pattern to production validation.
- Find-and-replace prep. Iterate on a `s/foo/bar/g` style replacement against representative input until the result matches expectations, then run the same replacement in your editor or with `sed`.
- Data extraction. Pull semver versions from a changelog, scrape JIRA ticket IDs from commit messages, or harvest URLs from a markdown document. Named capture groups make the resulting code self-documenting.
- Learning regex. Hover over each metacharacter while it is highlighted in your input to see how character classes, quantifiers, anchors, and groups interact.
Privacy and security
The regex engine is whatever the browser ships — V8 in Chrome, JavaScriptCore in Safari, SpiderMonkey in Firefox. Nothing is uploaded; the pattern runs against the test string entirely inside your tab. Patterns and test data are not URL-synced by default, so refreshing the page clears the input. Patterns that exhibit catastrophic backtracking will block the main thread of the tester (just like they would in production), so test pathological inputs against your own runtime before deploying — the browser tab will hang on truly degenerate cases until you close it.
Tips and pitfalls
- Catastrophic backtracking. Patterns like `(a+)+
toolrunner or `(a|aa)+` against long input run in exponential time. The 2016 Stack Overflow outage and the 2019 Cloudflare regex outage were both caused by this. Use atomic groups (Go RE2 / .NET) or restructure to avoid nested unbounded quantifiers. - `.` does not match newline. Set the `s` flag (dotall) when you want `.` to span line boundaries.
- Lookbehind support is recent. Variable-length lookbehind landed in ECMAScript 2018 and works in all modern browsers, but older runtimes (Node 8 and below, IE) reject the pattern at parse time.
- Unicode property escapes need `u`. `\p{Letter}`, `\p{Emoji}`, and similar escapes only work when the `u` flag is set; without `u` they are syntax errors.
- V8 vs RE2 vs PCRE. JavaScript regex is backtracking; Go RE2 is linear-time but lacks backreferences and lookbehind; PCRE is the superset most other tools (perl, grep -P, PHP) use. Patterns that pass here may need tweaks for those engines.
Frequently Asked Questions
- Which regex flavor does this tester use?
- JavaScript / ECMAScript regex, evaluated by your browser engine. That means full support for capture groups, named captures (`(?<name>...)`), lookbehind, and Unicode property escapes, but no atomic groups or possessive quantifiers (those exist in Java, .NET, and PCRE but not in ECMAScript).
- What is catastrophic backtracking?
- A regex that takes exponential time on certain inputs because the engine tries every possible match path. Classic patterns: nested unbounded quantifiers like `(a+)+`, alternations with overlap like `(a|aa)+`. The fix is to make the pattern unambiguous — use possessive quantifiers (in PCRE), atomic groups (in .NET / Go RE2), or restructure so each character has only one matching path.
- Are lookbehind and lookahead supported?
- Yes — both lookbehind (`(?<=...)`, `(?<!...)`) and lookahead (`(?=...)`, `(?!...)`). Variable-length lookbehind landed in ECMAScript 2018 and is supported in every browser shipped after 2019.
- How do I match Unicode characters?
- Set the `u` flag and use Unicode property escapes: `\p{Letter}` (any letter), `\p{Number}` (any number), `\p{Script=Hangul}` (specific script). Without `u`, `\p{...}` is a syntax error and `.` does not match astral-plane characters (above U+FFFF) correctly.
- Greedy vs lazy quantifiers — what is the difference?
- `*`, `+`, `?`, and `{n,m}` are greedy by default (they try to match as much as possible, then backtrack). Append `?` to make them lazy (match as little as possible, then expand): `.*?` matches the shortest possible string, `.+?` matches one-or-more lazily. Lazy quantifiers are essential when extracting text between delimiters.
- How do named capture groups work?
- `(?<name>...)` defines a named capture; `\k<name>` backreferences it within the pattern; `lt;name>` references it in a replacement template. Named groups make patterns self-documenting and survive refactors better than positional indices.
- When should I NOT use regex?
- When the input has nested or recursive structure — HTML, JSON, source code, paired delimiters. Use a real parser instead (DOMParser, JSON.parse, an AST library). The famous "do not parse HTML with regex" answer on Stack Overflow remains correct: regex describes regular languages, and HTML is not regular.
- Any tips for performance?
- Anchor your pattern with `^` or `\b` when possible to fail-fast on non-matches. Make alternations unambiguous so the engine never backtracks. Pre-compile patterns by storing them in a `RegExp` instance instead of recreating them in a hot loop. Profile in production with realistic input — a pattern that runs fast on test data may still be O(n²) on real input.
- How does this differ from Go RE2 or PCRE?
- JavaScript regex is a backtracking engine — it supports backreferences, lookbehind, and arbitrary lookaround at the cost of worst-case exponential runtime. Go RE2 is a finite-automaton engine — linear time guaranteed, but no backreferences or lookbehind. PCRE is a backtracking superset of JavaScript regex with extras like atomic groups and recursive patterns. Test patterns in the engine they will run in.