Universal Regex Tester & Builder

What this regex tester does

This is a free regex tester and builder that runs entirely in your browser — nothing you paste is uploaded, logged or stored. Type a pattern, paste text to test it against, and see every match highlighted immediately, with a match table, a cross-check receipt and a replace preview beneath it.

What makes it different is the claim in the flavor picker. Pick "Go RE2" or "POSIX ERE" and the tool does not quietly run your pattern through JavaScript's own RegExp with a different label on the dropdown — it parses and matches your pattern under that engine's actual rules, built from scratch in src/lib/tools/regex/ rather than borrowed from the browser.

One tester, every flavor

Eight flavors, each with its own capability table rather than a shared guess:

Regex flags explained — i, g, m, s, x and the rest

Flags sit outside the pattern and change how the whole thing is matched. They are also the most common source of a regex that looks right and quietly returns the wrong answer: a flag left off does not raise an error, it just reports 0 matches for a pattern that is fine. Every flag below has a toggle in the workbench above, and switching flavors re-labels them with that engine's own name for the same idea.

The four you will meet most often are i for case-insensitive matching, the global flag g for finding every match rather than stopping at the first, m for multiline anchors, and s — confusingly named Singleline in .NET and DOTALL in Python and PCRE2 — for letting a dot match a line break.

The one worth reading twice is m. Without it, ^ and $ mean the very start and very end of the whole text, so ^ERROR against a thirty-line log finds at most one match — on line one. With it, they mean the start and end of every line, which is almost always what someone pasting a log actually wants.

Why the same regex behaves differently in Java, Python and Go

"Regex" is not one language — it is a family of similar-looking grammars that disagree about basic things. A pattern that is correct in one engine can silently do something else entirely in another, and the differences below are the ones that hit ordinary patterns, not exotica.

Switch the flavor picker above on any pattern that touches one of these and the tool re-validates immediately, naming the exact construct that just became unsupported and why — rather than silently producing a different, plausible-looking answer.

Regex in the terminal — grep, sed, awk, ripgrep and PowerShell

A plain grep or sed uses POSIX Basic Regular Expressions by default, where (, ), { and } are literal characters unless escaped with a backslash — the reverse of every other flavor here. Add -E (or GNU's -r for sed) to get POSIX Extended Regular Expressions instead, which read the way most people expect. Both POSIX modes return the overall longest match rather than the first one a backtracker finds, which is why a|ab against "ab" matches a in a Perl-family engine and ab under grep -E. ripgrep uses the Rust regex crate by default — no backreferences, no lookaround — and only falls back to real PCRE2 semantics with its own -P flag. In PowerShell, a bare $1 inside a double-quoted -replace string is eaten by the shell before the regex engine ever sees it — use single quotes, or a variable, to keep it literal.

Explain any regex in plain English

Most of the time you are not writing a pattern — you are staring at one somebody else wrote, in a config file or a code review, trying to work out what it does before you dare change it. Paste it into the pattern box and the Explain panel reads it back as a sentence: what each group captures, what each quantifier repeats, which parts are optional and where the anchors bind. It is generated from the same parse tree the matcher runs, so the explanation cannot drift from the behaviour — if the engine disagrees with the English, the English is what changes.

This works in the direction people actually need most often, and it is the reason the tool is useful even if you never write a pattern of your own: what does this regex do is a harder question than does this regex work, and nothing about a wall of punctuation answers it on sight.

Build a regex from an example

If you can show the tool a line you want to match, you do not have to know the syntax at all. Paste a sample — a log line, an order number, a date — highlight the part that matters, and the Build from an example panel proposes a pattern that captures it, with the generalisations spelled out: whether those four digits should be exactly four, whether that hyphen is fixed, whether the case matters. You accept the ones you want.

The token chips beside it do the same job from the other end. Every construct in the cheat sheet below is a chip you can click into the pattern, spelled correctly for the flavor you have selected — Python's (?P<name>…) where Python needs it, \( and \{ where POSIX BRE needs those, rather than one spelling pasted everywhere and hoped for.

See the pattern as a diagram

The Diagram tab draws the pattern as a railroad diagram — the branching picture of every path through the expression, read left to right. Alternation becomes parallel tracks, a quantifier becomes a visible loop, an optional group becomes a bypass. For a pattern with three nested alternations it is usually faster than reading the source, and it makes one specific class of bug obvious on sight: a group that can match empty, which is the shape that turns into the backtracking problem below.

Copy the pattern as working code

A tested pattern still has to survive the trip into your codebase, and that trip is where correct patterns go wrong — the wrong escaping for the language's string literal, the wrong quoting for the shell, $1 eaten by PowerShell before the regex engine ever sees it. The Code tab writes the whole call for you, escaped for the target you pick:

• JavaScript / TypeScript (literal)
• JavaScript (new RegExp)
• Python (re)
• Java (Pattern)
• C# (Regex)
• PowerShell
• Go (regexp)
• PHP (preg_match)
• Ruby
• Rust (regex crate)
• Bash ([[ =~ ]])
• grep (BRE)
• grep -E (ERE)
• ripgrep
• sed -E
• awk
• jq
• SQL (PostgreSQL)
• SQL (MySQL)

Nineteen targets, including the ones that are hardest to get right by hand: a grep command with the pattern single-quoted so the shell leaves it alone, a jq test() call, a PostgreSQL ~ operator, and a PowerShell -match that survives the shell's own $ interpolation.

Lock the behaviour in with test cases

Under the pattern box are two lists: must match and must not match. Put your real examples in them — the three address formats that have to pass, the two that have to fail — and every edit to the pattern is checked against all of them instantly. It is the same discipline as a unit test, applied at the point where the pattern is still cheap to change, and it catches the classic regression: a tweak that fixes the case you were looking at and silently breaks one you fixed an hour ago.

The lists travel in the share link, so handing someone a pattern also hands them the cases it is supposed to satisfy.

Common regex patterns, ready to use

The pattern library in the workbench carries 27 patterns for the things people ask for most often. Every one of them is checked by our test suite against real must-match and must-not-match cases in every flavor it claims — a library entry whose cases fail turns the build red rather than becoming your bug. Where a pattern is a pragmatic approximation rather than a guarantee, it says so; that caveat is the most important column here.

The patterns above are the ECMAScript spelling, which every flavor here can express. Load one from the library in the workbench and it is rewritten for whichever flavor you have selected, or reports plainly that the flavor cannot express it — Go's RE2 has no lookaround, so a pattern that needs one is a compile error there, not a silently different result.

Catastrophic backtracking, and how to see it before production does

A pattern like (a+)+$ looks harmless and can take exponentially longer to fail as the input grows by a single character — the classic cause of a regex that "hangs" a service. This tool enforces a hard step budget (five million steps per run) so a pathological pattern reports "gave up after N steps" instead of freezing your tab, which is also why matching runs in a background worker rather than on the page itself. The Analyse tab goes further: it scans the pattern for the known-dangerous shapes, builds a real witness string, and runs it through our own matcher at growing sizes so you see the actual measured step counts — never a claim that a pattern is "safe," only what was actually tested. The Debug tab steps through one match attempt instruction by instruction, so you can see exactly where a slow pattern starts backtracking.

Which regex flavor should I test against?

Whichever one the pattern will actually run on — the point of this tool is that guessing shouldn't be necessary. If you're deploying to a Java service, test against Java, not ECMAScript; if the pattern is going into a sed -E script, test against POSIX ERE, where the leftmost-longest rule and the terminal quoting both matter.

It's also fair to say when another tool is the better choice. regex101 is the category leader for a reason: a wider flavor list, a step-by-step debugger, a saved-pattern library and a large community of examples. If an account and its own hosting model are fine for what you're testing, it's an excellent tool. This one is built around a narrower, more specific trade: no account, no server component of any kind for the matching itself — every flavor's engine ships as part of the page and runs in your browser, which matters most for production log lines, tokens, or anything you'd rather not paste anywhere else, cross-checked live against your own browser's engine on every run.

Per-flavor guides

Testing one specific engine's own rules in depth? Each flavor has its own guide — the quirks table, a worked example, and the FAQ people actually search for when a pattern behaves differently in production than it did in a generic tester. Every one opens this tool with that flavor already selected.

All regex flavor guides →

Regex cheat sheet

Every construct below is also a chip in the workbench above: click it and it goes into the pattern, spelled correctly for the flavor you have selected. The meanings are the same strings the chips' own tooltips carry, so this table cannot describe a construct differently from the thing that inserts it.

Privacy

Nothing you paste ever leaves your device. Parsing, validation and matching are computed by JavaScript running in your browser, in a background worker so a slow pattern never freezes the page. There is no server to send it to.