Text
Regex Tester with Live Match Highlighting
Test regular expressions with live highlighting, groups and replace preview.
Runs entirely in your browser — nothing you paste is uploaded or stored.
What is regex tester?
A regular expression describes a pattern of text, and getting one right almost always takes several attempts against real input. This tester runs your pattern as you type, highlights every match in the subject text, and lists each match with its position and captured groups — both numbered and named. It also previews replacements, so you can confirm a substitution does what you intend before running it against anything that matters. The engine is your browser's own JavaScript engine, so behaviour matches JavaScript exactly by default. A Flavour selector lets you write a pattern in PCRE, Python, Java, .NET or Go syntax instead — the tool translates the syntax differences it knows about (named groups, POSIX classes, `\A`/`\Z` anchors and more) before running it, and explains every translation it made so you know exactly what changed.
When to use it
- Building a validation pattern and checking it against a list of inputs that should match and inputs that should not.
- Extracting a field from semi-structured text such as log lines, and confirming the capture group grabs exactly the right part.
- Working out why an existing pattern fails on a particular input, by watching the highlighting change as you adjust it.
- Previewing a find-and-replace with back-references before applying it across a codebase.
How to use this tool
- Type your pattern into the expression field — write it without the surrounding slashes, or pick a starting point from the "Common patterns" menu.
- Toggle the flags you need. Global finds every match rather than just the first; ignore case does what it says.
- Paste your test string below. Matches highlight live, and each one is listed with its position and groups.
- If your pattern has capturing groups, the "Pattern groups" panel tints each one — the same tint reappears on its value under Match details, so you can see which part of the pattern produced which captured text.
- Tick "Show replace" to add a replacement field, where $1 or $<name> insert captured groups.
Example
Extracting the user and domain from email addresses with named groups.
Input
(?<user>[\w.+-]+)@(?<domain>[\w-]+\.[\w.]+)Output
Match #1 ada@example.com user=ada domain=example.com
Match #2 grace.hopper@navy.mil user=grace.hopper domain=navy.milNamed groups make a pattern far easier to read six months later than $1 and $2 do, and every modern JavaScript engine supports them.
Validating email addresses
The pattern in the example above is a reasonable approximation, not a correct email
validator — the actual grammar in RFC 5322 permits quoted strings, comments and nested
constructs that no readable regex handles. For real validation, check that the address
contains an @ with something plausible on each side, then send a confirmation email.
That is the only test that establishes what you actually care about.
Frequently asked questions
Which regex flavour does this use?
By default, JavaScript's, because the pattern runs in your browser's native engine. The Flavour dropdown above the pattern field also offers PCRE (PHP/Perl), Python, Java, .NET and Go — picking one translates that flavour's syntax differences (named groups, POSIX classes, `\A`/`\Z` anchors, possessive quantifiers, atomic groups) into JavaScript before running, and shows a note for every translation made. There is still only one real engine running underneath (see the next question), so this is a syntax bridge, not five separate regex engines.
If it only runs JavaScript, how is the flavour selector not fake?
It genuinely changes what your pattern is interpreted as, honestly. Choosing PCRE or Python lets you type `(?P<name>...)` and see it translated to JavaScript's `(?<name>...)` with a note saying so, rather than being told it's a syntax error. Choosing Go is the strictest case — Go's RE2 engine refuses to run lookahead, lookbehind or back-references at all, because supporting them would break its guarantee of linear-time matching, so this tool rejects those constructs outright under Go rather than pretending to approximate something RE2 genuinely can't do. What it cannot do is reproduce subtler behavioural differences between real engines (exact backtracking order, Unicode case-folding edge cases) — for that, test the pattern in its real target language before shipping it.
Why does my pattern match nothing when it works elsewhere?
The most common cause is a missing global flag, which limits you to the first match. The second is escaping: if you copied the pattern out of a string literal in code, it may contain doubled backslashes that need reducing to single ones here. Enter the raw pattern, not the quoted string version of it.
What does the warning about matching an empty string mean?
Your pattern can succeed while consuming no characters — typically because a quantifier like * or ? allows zero repetitions. This is usually a mistake; the fix is often changing * to +. It also causes infinite loops in naive matching code, which is why the tool flags it explicitly.
Is my test data sent anywhere?
No. The pattern and the subject text stay in your browser and are executed by its built-in regular expression engine. Nothing is transmitted, so you can safely test patterns against real log excerpts or production data.
Why is my regex extremely slow on some inputs?
Probably catastrophic backtracking. Nested quantifiers such as (a+)+ can cause the engine to explore exponentially many ways to match a failing input, hanging for seconds or longer on a string of modest length. This is a real denial-of-service risk if the pattern runs on user input. Simplify the nesting, or anchor the pattern so it fails fast.