Regex tester, named groups, replacement preview and saved patterns
Paste a JavaScript regex, throw some real text at it, and watch what actually happens. You get the matches, where they start and end, numbered groups, named groups, a replacement preview. Save a pattern in your browser for later. There’s a copy-snippet button too. Honestly, the part most people skip is the safety check, and that’s the part I’d read twice before this regex goes anywhere near production.
This runs in your browser, on the JavaScript engine. Other languages handle syntax and escaping a bit differently, and some features just aren’t there, so don’t assume a pass here means a pass everywhere.
A regex tester should show what the pattern actually did
Regex is compact. That’s the appeal, and it’s also where it bites you. A pattern can nail your one tidy example and then quietly fall apart on a multiline log, on Unicode text, on the near miss that should’ve been rejected but slipped through. So a tester that just says “matched” isn’t enough. I want to see the indexes, the captured groups, the named ones, what the replacement does, which flags are on, and whether my test cases hold. Before any of it gets copied anywhere.
That’s roughly what this thing does. Everything runs locally. It highlights the hits in your sample, tells you where each one starts and stops, breaks out numbered and named captures, shows you the replacement before you commit to it. There are starter patterns if you don’t feel like writing one from scratch. Patterns you save stick around in browser storage. And it’ll spit out a snippet for JavaScript, for PHP-style PCRE, for Python (with notes on how the named groups change shape going over to Python, because they do).
How to test a regular expression safely
Start with messy text, not the clean example you wrote in your head. Drop in lines that should match. Drop in some that should fail, those are the ones that catch real bugs. Then ask yourself one thing: are you fishing values out of a blob, or validating a whole field? Different jobs. And the flags matter more than people think. Global changes how many results come back. Multiline rewires what the anchors mean. DotAll lets a dot swallow newlines. Case-insensitive can paper over an assumption you didn’t know you were making.
- Matches give you the value plus exactly where it sits, start index through end.
- Groups pull out the numbered captures, and the named ones too, assuming the engine plays along.
- Replace preview is the safety net. It shows the damage before a bad cleanup hits a file or a database.
- Saved patterns just hang around in the browser so you can come back to a draft.
- Safety notes flag the usual suspects: greedy wildcards, nested quantifiers, and the jobs you really should hand to a parser instead.
Common regex debugging examples
Log cleanup eating too much? Nine times out of ten it’s a greedy .* somewhere, so go find it and throw a few different lines at it. Using an email pattern for signups? Fine, but treat regex as the doorman, not the bouncer, you still confirm the address some other way. URL match dragging a trailing comma or period along with it? Tighten the boundary, or just trim the punctuation in code afterward, whichever’s less painful. And JSON, HTML, an actual programming language? Don’t. Reach for a parser. Keep regex for the small stuff.
Common questions
Are JavaScript regex and PCRE the same?
Nope. Close cousins, sure, a lot overlaps. But flags, lookbehind, how named groups are written, the escaping rules, those drift apart. So test it where it’ll actually run.
Can regex validate every email address?
Not in any way you’d want to ship, honestly. The full spec is a nightmare. Use regex to weed out the obvious junk, then prove the address is real by emailing it or whatever your app does.
Can regex parse HTML or JSON?
It can grab a small fragment here and there. For actual parsing, though, use a real parser. Trust me on this one.
Which regex flavor does this tester use?
JavaScript, the ECMAScript flavor, because that’s the engine in your browser doing the work. A few PCRE or Python things (some lookbehind tricks, the way named groups are spelled) won’t behave the same over there.
What do the g, i and m flags do?
g keeps going past the first hit and grabs them all. i drops the case sensitivity. m is the sneaky one: it makes ^ and $ snap to the start and end of every line, not just the whole string.
Why is my regex slow or freezing the page?
Catastrophic backtracking, almost certainly. It’s that nasty pattern shape like (a+)+ hitting input that doesn’t quite match, and the engine tries every combination before giving up. Fix is to rewrite the thing so the pieces stop overlapping in ambiguous ways. Easier said than done sometimes, I know.
