Regex Explainer — Turn a Regular Expression into Plain English
Paste a regular expression and read what every piece of it does, in order, in plain English. Groups are indented, quantifiers say how many times, character classes are spelled out, and the flags get their own list. There is a box underneath for trying it on your own text, and nothing you type leaves the browser.
Most regex sites are testers that happen to explain; the explanation sits in a panel you have to hunt for, and on a phone it barely fits. This page is the other way round — the explanation is the page. It is useful when you have inherited a pattern from a codebase, a Stack Overflow answer, or a config file and need to know what it actually matches before you trust it.
The parts people get wrong
Three things cause most confusion. Greedy versus lazy: .* takes as much as it can and then backs off, while .*? takes as little as possible — the difference between matching one HTML tag and matching everything between the first and last. The dot: it matches any character except a newline, unless the s flag is set. Anchors: ^ and $ mean start and end of the whole string until you add the m flag, at which point they mean start and end of each line.
Groups, lookarounds, and what gets captured
Round brackets do two jobs at once: they group things together, and they remember what matched. If you only need the grouping, (?:…) avoids the cost and keeps your capture numbers stable. Lookarounds — (?=…), (?!…), (?<=…), (?<!…) — assert that something is or is not there without consuming it, which is how password rules like “must contain a digit” are written. Lookbehind is the newest of the four; Safari only shipped it in version 16.4, so very old browsers will throw on a pattern that works everywhere else.
When a regex is the wrong tool
Nested structures — HTML, JSON, source code — are not regular, and a pattern that appears to parse them will fail on the first unusual input. Patterns built from nested quantifiers such as (a+)+ can also take exponential time on a string that nearly matches, which is how a single request can pin a server’s CPU. If the explanation below reads like a small program, that is usually the signal to use a parser instead.
Related: run a pattern against a long sample in the regex tester, decode file permissions with the chmod calculator, or read a schedule line with the cron expression generator.
How to use Regex Explainer
- Paste the expression into the box — without the surrounding slashes, or with them if that is how you copied it. Put any flags in the small field on the right.
- Read the breakdown underneath. Each row shows one token and what it does; rows inside a group are indented so the structure is visible.
- Check the flags list. A pattern can behave completely differently with g, i, m, or s set.
- Paste a sample into the test box to see what the expression actually matches in your own data.
- Use one of the example patterns if you want to see how a typical email, URL, or password rule is put together.
Features
- Token-by-token explanation — every anchor, class, quantifier, group, lookaround, and backreference described in plain English.
- Group nesting shown by indentation — so you can see what belongs to what without counting brackets.
- Flags explained separately — including the ones that change what ^, $, and the dot mean.
- Live match testing — paste sample text and see the matches, with invalid patterns reported the way the JavaScript engine reports them.
- Worked examples — email, URL, date, password rule, and hex colour patterns to load with one click.
- Nothing leaves the browser — the pattern and the sample text are never sent anywhere.
Frequently Asked Questions
What does this regex mean?
Paste it above and the page lists every token with a plain-English description — for example ^ is “the start of the text”, \\d{3} is “any digit, repeated exactly three times”, and (?=.*[A-Z]) is “somewhere ahead there must be a capital letter, but it is not consumed”. Groups are indented so nesting is visible.
What is the difference between .* and .*?
Both match any run of characters, but .* is greedy: it grabs as much as possible and gives characters back only if the rest of the pattern fails. .*? is lazy: it takes the shortest run that lets the pattern succeed. On <a><b>, the pattern <.*> matches the whole string while <.*?> matches just <a>.
Why does my pattern not match across lines?
The dot excludes newlines by default. Add the s flag to make it match them. Separately, ^ and $ mean the start and end of the whole string unless you add the m flag, which makes them match at each line break instead.
When should I use (?:...) instead of (...)?
Use (?:…) whenever you only need to group something — for example to apply a quantifier to several characters at once. A plain (…) also captures, which costs a little performance and, more importantly, shifts the numbering of every group after it.
Can a regular expression parse HTML or JSON?
Not reliably. Both allow arbitrary nesting, which regular expressions cannot express, so any pattern that appears to work will break on legal input it did not anticipate. Use a parser — DOMParser for HTML, JSON.parse for JSON — and keep the regex for flat, predictable strings.
What is catastrophic backtracking?
When nested quantifiers such as (a+)+$ meet a string that almost matches, the engine can try an exponential number of paths and hang. It is a real denial-of-service vector when patterns run against user input. The fix is to avoid nesting quantifiers over the same characters and to anchor patterns tightly.
Does this page support flavours other than JavaScript?
The live testing uses the JavaScript engine in your browser, so that is the dialect it validates against. The explanations cover syntax shared across PCRE, Python, and Java, but named groups, lookbehind, and Unicode property escapes differ between languages — check your own engine before relying on them.