Regex Tester & AI Explainer AI

A regular expression — regex for short — is a small language for describing patterns in text. Rather than searching for one fixed word, you describe the shape of what you are looking for: a phone number, a hex colour, a date, an email address, or the whitespace between words. Regex powers find-and-replace in editors, form validation, log parsing, URL routing, and countless data-cleaning tasks.

The trouble is that regex is famously hard to read. It is written to be compact, not communicative, and a pattern you wrote confidently in the morning can be genuinely opaque by the afternoon. This tester pairs a live, visual matcher with an AI explainer so you can both see what a pattern matches and read a plain-English breakdown of why.

Enter your pattern in the expression field, toggle the flags you need, then paste sample text below. Every match is highlighted in the preview, the match count updates instantly, and any capture groups appear in the results table. When a pattern gets dense, press Explain this regex for a token-by-token walkthrough with example matches.

The most productive way to work is to build the pattern up rather than write it in one go. Start with the simplest thing that matches your target, confirm it highlights what you expect, then add one constraint at a time. Paste in text that should not match as well as text that should — a pattern that matches everything you want is only half correct if it also matches things you do not.

These are the building blocks you will reach for most often:

Flags are easy to overlook and they alter the meaning of a pattern completely. The same expression can find one match or two hundred depending on which are set.

The m flag is the one most often missing. Without it, ^ and $ anchor to the whole string, so a pattern intended to check each line of a log file quietly matches only the very first and last positions.

By default, quantifiers are greedy: they consume as much text as possible and then give characters back only if the rest of the pattern fails. This produces the single most common regex surprise.

Adding ? after a quantifier makes it lazy, stopping at the first position where the rest of the pattern can match. Often the cleaner fix is to be explicit about what you do not want: <[^>]+>says “anything that is not a closing bracket”, which is both faster and clearer than relying on laziness.

Parentheses do two jobs: they group part of a pattern, and they capture what that part matched so you can use it afterwards. Groups are numbered from left to right by their opening bracket, with group 0 being the whole match.

When a pattern has several groups, numbering becomes a liability — insert one group near the front and every later reference shifts. Named groups solve this: (?<year>\d{4}) can be referenced as $<year> in a replacement and read as match.groups.year in JavaScript. If you are grouping purely for alternation or quantification and do not need the captured text, use a non-capturing group (?:…) to keep the numbering clean.

Treat these as starting points rather than finished validators. The email pattern above accepts the addresses you will meet in practice; it is not a complete implementation of the RFC, and no reasonable regex is.

Regex is superb at matching flat, local patterns and genuinely bad at anything with nesting or structure. Knowing where the line falls saves a lot of wasted effort.

• Parsing HTML or XML. These formats nest arbitrarily deep, and regular expressions cannot count nesting. Use a real parser — DOMParser in the browser, a library on the server.
• Parsing JSON. Same reason, and JSON.parse already exists and is correct.
• Validating email for real. The only reliable test that an address works is sending mail to it. Use a loose pattern to catch typos, then verify by email.
• CSV with quoted fields. Quoting, escaping, and embedded newlines defeat the naive patterns quickly. Use a CSV parser.
• Anything a simple string method does. includes, startsWith, and split are clearer and faster than a regex when they suffice.

Catastrophic backtracking

A pattern with nested quantifiers over overlapping character sets — the classic shape being (a+)+b — can take exponential time on input that almost matches. On a server handling user-supplied input this turns a regex into a denial-of-service vulnerability, known as ReDoS. If a pattern must run on untrusted input, keep quantifiers from nesting, prefer explicit negated character classes over .*, and test with a long non-matching string before shipping.

This tester uses the JavaScript (ECMAScript) engine — the same one in your browser and in Node.js. Most core syntax is shared across languages, but the details diverge. PCRE and Python support recursion, possessive quantifiers, and atomic groups that JavaScript does not; lookbehind is supported in modern JavaScript but not in every runtime you might target; and named group syntax varies between flavours. If you are writing a pattern for Python, Java, Go, or a database engine, confirm it there before relying on results from here.