Regex Tester

Test a JavaScript regex on real text, with named groups, replace preview and saved patterns.

This regex tester runs a JavaScript regex against real text right in your browser and shows what the pattern actually did. You get the matches with their start and end indexes, numbered groups, named groups, a replacement preview before you commit, and positive plus negative test lines that catch the bugs your tidy example hides. There are seven starter patterns for email, URL, IPv4, UUID, ISO date, slug and log levels, and you can save your own in browser storage. It writes copy-ready snippets for JavaScript, PHP style PCRE and Python, and flags greedy wildcards, nested quantifiers and the jobs you should hand to a parser instead. Nothing leaves your machine.

100% in your browser. Nothing you type ever leaves this page.

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 is a copy-snippet button too. Honestly, the part most people skip is the safety check, and that is the part I would read twice before this regex goes anywhere near production.

Regex pattern

Flags

Pattern library

Snippet

Replace with

Saved pattern name

Saved

Sample text

Positive test lines

Negative test lines

This runs in your browser, on the JavaScript engine. Other languages handle syntax and escaping a bit differently, and some features just are not there, so do not assume a pass here means a pass everywhere.

A regex tester should show what the pattern actually did

A good regex tester shows the indexes, the captured groups, the named ones, the replacement output and the flags that are on, not just a green light that says "matched". Regex is compact. That is the appeal, and it is 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 have been rejected but slipped through. So you want to see all of that, before any of it gets copied anywhere.

That is 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 do not feel like writing one from scratch. Patterns you save stick around in browser storage. And it will 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 did not 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 is a greedy wildcard 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 is less painful. And JSON, HTML, an actual programming language? Do not. Reach for a parser. Keep regex for the small stuff.

Frequently asked 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 will actually run.

Can regex validate every email address?

Not in any way you would 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.

Why is my regex slow or freezing the page?

Catastrophic backtracking, almost certainly. It is that nasty pattern shape like a nested quantifier hitting input that does not quite match, and the engine tries every combination before giving up. Rewrite the thing so the pieces stop overlapping in ambiguous ways.