Regex Tester

How to use the Regex Tester

1. Type your pattern in the pattern box, without the slashes you may be used to from code — the flags have their own tick boxes underneath. Testing runs automatically as you type.
2. Paste the text you want to test against. Use realistic text: a pattern that behaves on a tidy example can behave very differently on the ragged data you actually have.
3. Read the highlights first, then the table. Highlighting shows where matches start and end; the capture-group table shows exactly which characters each group captured in each match, including named groups.
4. Add a replacement if your goal is a search-and-replace: type it in the replacement box using $1, $<name>, $&, $` , $' or $$ and check the preview before trusting it in your editor.
5. Short on ideas or debugging a token? Load one of the twelve library patterns to see a working example with an explanation, and keep the cheat sheet open while you edit — most pattern bugs are one wrong token.

Worked example

Select Load sample and the workspace fills with a pattern that pulls email addresses apart: (?<user>[A-Za-z0-9._%+-]+)@(?<domain>[A-Za-z0-9.-]+), with the g flag set and the replacement $<user> at $<domain>. The test text is two lines: “Contact amara.osei@example.com or tom.ellery@riverside-books.co.uk for details.” followed by “Backup address: support@atoztools.pro (replies within one working day).”

The tool finds exactly 3 matches. The first starts at character index 8 and is amara.osei@example.com; its groups table row reads group user = amara.osei and group domain = example.com. The other matches start at indexes 34 and 96 (tom.ellery@riverside-books.co.uk and support@atoztools.pro). The replace preview rewrites each address into words — “amara.osei at example.com”, “tom.ellery at riverside-books.co.uk”, “support at atoztools.pro” — leaving the rest of the text untouched. These results were produced by running the runMatch function from the shipped regex-tester.js on exactly this pattern, text and replacement, and the same function is what the workspace runs (inside its worker) when you select the button.

Pattern:     (?<user>[A-Za-z0-9._%+-]+)@(?<domain>[A-Za-z0-9.-]+)   flags: g
Match 1:     amara.osei@example.com   (index 8)   user=amara.osei   domain=example.com
Replaced:    Contact amara.osei at example.com or tom.ellery at riverside-books.co.uk
             for details. Backup address: support at atoztools.pro (…)

What this tool does, and why it matters

A regular expression is a tiny program for describing text: not “find this exact word”, but “find anything shaped like this” — a date, a product code, an address, a log line with a number in it. Developers use them to validate form input, extract fields from files, clean up data and power the find-and-replace in every serious text editor. They are also famously easy to get subtly wrong. A pattern reads as dense punctuation, its behaviour depends on which characters around it happen to appear in your data, and a mistake usually fails quietly: the pattern simply matches a little too much, a little too little, or — in the worst case — takes minutes over a single string.

That is why testing against real text, with the matches made visible, matters more than writing the pattern carefully. Highlighting shows you the match boundaries your mental model predicted, and the capture-group table shows what each group actually captured — the difference between a group that matched the domain and a group that accidentally swallowed the whole address is obvious in a table and invisible in the pattern itself. The replace preview closes the loop: most real-world regex work is not searching but transforming, and a replacement that expands $1 or $<name> wrongly will corrupt data at exactly the moment you apply it everywhere.

Two honest details define this tester. First, the flavour: it runs the JavaScript engine, and says so. Regular expressions are a family of related dialects, not one language — PCRE, used by PHP and many command-line tools, supports possessive quantifiers, atomic groups and constructs such as \K that JavaScript does not have, while JavaScript offers lookbehind and Unicode property classes in its own spelling. A pattern can be valid in one engine, invalid in another, and quietly different in a third. Testing here tells you the truth about JavaScript behaviour; before shipping a pattern to a PHP, Python or .NET target, test it there too.

Second, the safety limit. A pattern with nested repeats can force the engine into catastrophic backtracking, trying an astronomical number of ways to split a string before giving up — a classic way to freeze a browser tab or hang a server (a failure mode known as ReDoS). Here, evaluation runs in a Web Worker under a hard one-second limit: a runaway pattern is stopped and explained, and the page never freezes. The “classic slow pattern” button loads the textbook example so you can watch that protection work instead of taking our word for it.

Common errors, and the limits of this tool

Invalid patterns. An unclosed group or character class, a quantifier with nothing to repeat, or a trailing backslash all stop the test before it starts. The error box shows the engine’s own message and, where a position can be derived from the pattern — the unclosed bracket, for instance — an approximate character position. It is labelled approximate because the JavaScript engine reports no position of its own; treat it as the neighbourhood of the problem, not a promise.

“Pattern too slow” is information, not a verdict on the pattern alone. Backtracking blow-ups depend on the combination of pattern and text: ^(a+)+$ is instant on matching text and hopeless on a long near-miss. When you hit the limit, simplify the pattern: avoid nesting one repeat inside another over the same characters, bound repetitions with {n,m} where you can, anchor both ends, and make adjacent groups claim disjoint character sets so the engine has fewer ways to divide the string. Note that JavaScript has no atomic groups or possessive quantifiers — the standard PCRE fix — so restructuring the pattern is the available remedy here.

Engine limits. This tester speaks JavaScript regex only: no PCRE-only constructs, no recursion, no conditionals. Match collection stops at 1,000 matches per test (the run tells you when the cap was hit, and the groups table prints the first 200 rows). The sticky y flag anchors matching at the current search position, which for a single test means the start of the text unless the pattern can match there — an empty result with y set is usually that, not a bug. Zero-width matches (from lookaheads or an empty pattern) are shown as thin markers in the highlight and as empty full matches in the table. Very old browsers without Web Worker support run the same code on the main thread instead, where the one-second timeout cannot interrupt a pattern mid-run — the one environment in which a pathological pattern can still stall the page.

Frequently asked questions