Regex to English: Understand Any Pattern
Regular expressions are dense by design — a single line can encode a surprisingly complex matching rule. This tool parses your pattern into its structural pieces (literals, character classes, groups, quantifiers, alternation) and explains each one in plain English, so you can understand an unfamiliar regex from a codebase or verify your own pattern does what you think it does.
Parsing happens with a hand-written recursive-descent parser, the same general technique real regex engines use.
Why a Structural Breakdown Beats a Single Sentence
A one-line summary of a complex pattern is often more confusing than the regex itself. This tool breaks the top-level sequence into numbered pieces — so you can see exactly which part of the pattern matches the '@' in an email, versus which part validates the domain — rather than one dense paragraph.
How Lookaheads and Lookbehinds Are Explained
Lookarounds are one of the most commonly misunderstood regex features because they match a position, not text — `foo(?=bar)` matches 'foo' only when followed by 'bar', but the 'bar' itself isn't part of the match. The explanation calls this out explicitly, noting the lookaround content 'isn't included in the match.'
Reading Quantifiers Correctly
`{2,}` means 'two or more', not 'exactly two, then more of something else' — a distinction that trips up many regex readers. Each quantified piece is explained with its exact repeat range and, when present, whether it's lazy (matches as little as possible) rather than the default greedy behavior.
Practical Examples
Understanding an Email Pattern
Breaking down ^[\w.+-]+@[\w-]+\.[a-zA-Z]{2,}$
- 1.Paste the pattern
- 2.See each segment (local part, @, domain, TLD) explained separately
Checking a Lookahead
Verifying foo(?=bar) matches position, not text.
- 1.Paste foo(?=bar)
- 2.Explanation clarifies 'bar' isn't consumed by the match
Supported Syntax
- Anchors: ^ $ \b \B
- Character classes: [...] [^...] \d \w \s
- Quantifiers: * + ? {n,m}, greedy and lazy
- Groups: capturing, non-capturing, named
- Alternation: |
- Lookahead/lookbehind: (?=) (?!) (?<=) (?
Good Use Cases
- Understanding an unfamiliar regex in someone else's code
- Debugging why a pattern doesn't match what you expect
- Learning regex syntax by seeing patterns explained piece by piece
- Documenting a complex validation pattern for a teammate
Frequently Asked Questions
How does this tool understand my regex?
It's a hand-written recursive-descent parser that walks your pattern character by character, building a tree of groups, alternations, character classes, and quantifiers — the same general approach real regex engines use internally — then converts that tree into English.
What regex syntax is supported?
Anchors (^ $ \b \B), character classes ([...] and [^...]), shorthand classes (\d \w \s and their negations), quantifiers (* + ? {n,m} including lazy versions), groups (capturing, non-capturing, named), alternation (|), backreferences, and lookaheads/lookbehinds.
What isn't supported?
Unicode property escapes (\p{...}), some rarely-used flag-specific behaviors, and a few obscure edge cases in nested character class syntax. If parsing fails, the tool tells you rather than guessing.
Why does the tool also validate my pattern with `new RegExp()`?
Before attempting its own explanation, the tool first tries to compile your pattern with JavaScript's native RegExp constructor — if that throws, your pattern has a genuine syntax error, and the tool shows you that native error message rather than a confusing parse failure from its own explainer.
Is my pattern sent anywhere?
No, parsing and explanation happen entirely in your browser.