Regex Tester
Test JavaScript regular expressions against sample text in your browser. See every match, index, and capture group instantly. No signup.
Regex Tester
Runs entirely in your browser — no server calls, no tracking.
Enter a pattern and sample text, then click Test regex.
🔒 Your data never leaves this tab. This tool has no backend.
About the Regex Tester
A regex tester runs a JavaScript RegExp against any text you paste and instantly shows every match, its start index, and any named or numbered capture groups. Use it to validate route patterns, test data-extraction rules before committing to code, or debug why a filter is matching too broadly or too narrowly.
How to use this tool
Paste your regular expression into the Pattern field, optionally set flags (g for global, i for case-insensitive, m for multiline), then paste sample text. Results update live as you type. The output shows each match with its zero-based index so you can map results back to your source string.
Common patterns
Route parameters: /users/([a-zA-Z0-9_-]+). Email addresses: [a-zA-Z0-9._%+\-]+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,}. ISO dates: \d{4}-\d{2}-\d{2}. Slug validation: ^[a-z0-9]+(-[a-z0-9]+)*$. These are starting points — always test against real production data before shipping.
JavaScript uses Perl-compatible regex with some differences: no lookbehind in older engines, no possessive quantifiers, and \d does not match Unicode digits unless you use the u flag. Test in this tool with the same JS engine your app uses to avoid cross-environment surprises.
Regex flavours: JavaScript, Java, Python and PCRE
Regular expressions look portable and mostly are, but the differences between engines cause real bugs when a pattern moves between languages.
| Flavour | Worth knowing |
|---|---|
| JavaScript | Lookbehind is recent; named groups are (?<name>); no \A or \z |
| Java | Patterns live in strings, so every backslash is doubled |
| Python | Use raw strings (r"...") to avoid the same doubling |
| PCRE (PHP, grep -P) | The most feature-rich; patterns need delimiters in PHP |
This tester uses the JavaScript engine, which covers the overwhelming majority of everyday patterns identically to the others. The doubled-backslash problem is a string literal issue, not a regex one: \d here becomes "\\d" in Java and r"\d" in Python.
The mistakes that cost the most time
Greedy quantifiers. .* matches as much as possible, so <.*> swallows an entire line of HTML rather than one tag. Use .*? for the shortest match.
Unescaped dots. . matches any character. To match a literal full stop, escape it: \.
Catastrophic backtracking. Nested quantifiers such as (a+)+ can take exponential time on a non-matching input — a real denial-of-service risk when the pattern runs against user input.
Anchors. Without ^ and $, a pattern matches anywhere in the string, so a “validation” regex may accept input with junk either side.
When not to use regex
Do not parse HTML, JSON or XML with it — those are nested structures and regex cannot reliably describe them. Use a parser. And email validation is far harder than it looks: check for an @ with something plausible either side, then send a confirmation message.
Frequently asked questions
For the vast majority of patterns, yes — this uses the JavaScript engine, which shares its core syntax with Java, Python and PCRE. The difference you will hit is string escaping, not regex: \d here becomes "\\d" in a Java string and r"\d" in Python. Test the pattern here, then escape it for your language.
Almost always a greedy quantifier. .* matches as much as it can, so <.*> consumes a whole line of HTML instead of a single tag. Add a question mark to make it lazy — .*? — and it will take the shortest match instead.
It is when nested quantifiers such as (a+)+ force the engine to try an exponential number of paths before failing. On a long non-matching input the pattern can hang for minutes. If your regex runs against user input this is a genuine denial-of-service risk, so avoid nesting quantifiers.
Only loosely. The full specification allows far more than people expect, and strict patterns reject valid addresses. Check there is an @ with plausible text either side, then send a confirmation email — delivery is the only real proof an address works.
No, not reliably. Both are nested structures and regular expressions cannot describe arbitrary nesting. A pattern that works on your sample will break on valid input with different nesting or attribute order. Use a proper parser instead.
g (global — find all matches), i (case-insensitive), m (multiline — ^ and $ match line boundaries), s (dotAll — dot matches newlines), u (unicode), d (indices — adds start/end index per capture), y (sticky). Combine them freely: gim.g flag — without it, matchAll will throw. Another cause: your app escapes backslashes differently in string literals (\\d vs \d). Always compare how the pattern is constructed in code vs what you type here.(?=pattern) asserts the pattern exists ahead without including it in the match. Use a lookbehind (?<=pattern) to assert what precedes. This tool shows zero-length matches at their position in the text.(?<name>...) syntax. The output shows capture groups by index; named groups can be accessed as m.groups.name in your code.Need production-grade custom software?
ruxox builds web apps, APIs, and automation tools for growing businesses. Free estimate in 48 hours.