Test a pattern against real text and see every match.
Enter a pattern to see matches.
Your pattern and text stay in this tab.
Write a pattern, paste the text you are matching against, and see every match highlighted as you type — with the capture groups listed underneath, since those are usually the reason you wrote the pattern at all.
The matching runs in a background worker that is stopped after a second and a half. That is not caution for its own sake: a pattern with nested quantifiers, something as ordinary as (a+)+, can take exponentially long on text that nearly matches, and on the main thread that is not a slow tool but a frozen tab. Here it stops and explains itself.
Everything happens on your device, which matters when the text you are testing against is a real log file or a customer record rather than an example.
Getting it right against real text first is far faster than a cycle of edit, run, squint at the output.
Pasting an inherited regex with real input is the quickest way to find out what it actually matches, as opposed to what the comment claims.
Test the addresses, postcodes or phone numbers that should pass and the ones that should not, in one place, before shipping the rule.
Capture groups are listed per match, so you can confirm the right parts are being captured before writing the extraction.
Just the expression — the slashes are shown for you. It is checked as you type, and a pattern that will not compile says so immediately.
g for every match rather than the first, i to ignore case, m so ^ and $ match at line breaks, s so the dot matches newlines, u for full Unicode.
Matches are highlighted in place, so you can see what is being caught and — just as usefully — what is not.
Each match's groups are listed below, named groups included, so you can confirm the pattern captures the parts you want.
JavaScript's, since it runs in your browser. It is close to PCRE for everyday patterns, but lookbehind, named groups and Unicode property escapes differ from Python, Go and PHP. Check the target language for anything exotic.
It took more than a second and a half. That is almost always catastrophic backtracking — nested quantifiers like (a+)+ or (.*)* against text that nearly matches, where the engine explores exponentially many possibilities. It is worth fixing rather than working around: the same pattern would hang a server.
The first 500 are shown, which keeps the page responsive on a large file. The count indicates when there were more.
The tool always finds every match so you can see them all. The flag is still shown because it changes how the same pattern behaves in your code, where without g most methods return only the first match.
No. Both the pattern and the text stay in this browser tab — worth knowing when you are testing against a real log file.