Free online regex explanation tool. Explains regex pattern segment by segment, helps understand and learn regular expressions.
TL;DR: Free regex explainer that breaks down regex syntax segment by segment with annotations. Supports lookarounds and named groups, runs locally.
For local tools, open DevTools → Network and search your input — it should not appear in requests.
Next steps
Usage Guide
Reading a regex you did not write — or one you wrote three months ago — is a shared developer pain. This tool splits a pattern into tokens (metacharacters, greedy/lazy quantifiers, classes, captures, named groups, lookarounds, Unicode properties), explains each in plain language, and flags risks such as nested quantifiers. Parsing stays in your browser; the pattern never uploads.
1. Explain a pattern
The explainer answers "what does this pattern say?", not "does it match my text?". Verify matches in the Regex Tester next door. The complete workflow is understand first, then verify.
- Paste a bare pattern or a /pattern/flags literal (slashes are stripped and detected flags are shown; apply flag semantics in the tester).
- Tokens stay intact for lazy quantifiers (*? / +? / ?? / {n,m}?), lookbehind (?<= / (?<!, named groups (?<name>, and \p{…} / \u{…}.
- Each row shows "token → meaning" with #n badges on captures; named groups show both name and index. Amber warnings cover nested quantifiers, unclosed classes, and unbalanced parentheses.
2. When to use the explainer instead of the tester
Common mistake: treating the explainer as a full debugger. It does not apply /g, /m, or /u match semantics, and it never runs a match. Flag traps (Chinese needing /u + \p{L}) belong in the diagnostic table, then the tester. A nested-quantifier warning means rewrite before wiring the pattern to user input.
- Inheriting complex validation rules: emails, phones, URLs, password strength — unpack before you edit.
- Code review: confirm lazy quantifiers and named groups mean what the author intended.
- Learning: map every symbol in a real pattern instead of memorizing a cheat sheet.
- Debugging "it matched but the capture is wrong": flatten groups to see which indices (?: ) and lookarounds skip.
3. Three checks while reading the breakdown
After reading the explanation, paste the same pattern into the Regex Tester and bomb it with real samples (empty string, edges, Unicode, newlines, deliberately non-matching long strings) before shipping. Explain → test → land.
- Greedy vs lazy: * / + are greedy; *? / +? / {n,m}? match as little as possible — the trailing ? is not a separate "optional".
- Capture indices: every ( ) and (?<name> ) takes a number; (?: ) and lookarounds do not — that decides match[1] and groups.name.
- Classes and Unicode: inside [ ] most metacharacters lose their magic, but leading ^ and - still matter; \p{…} needs the u flag in the engine.
FAQ
No — the regex is broken down in your browser, and your content isn't treated as upload material. That said, “runs locally” doesn't automatically mean “safe to share anywhere”: your downloads folder, clipboard, and screen sharing during meetings can leak too, so mind where you paste regexes with sensitive data.
Character classes, quantifiers, anchors, groups, backreferences, zero-width assertions (lookahead/lookbehind), named capture groups, and more — broken down segment by segment with each part annotated.
Not necessarily. Regex engines differ by dialect — the same construct can be supported in one engine and not another, with lookarounds and backreferences the classic divergences. The explanations here are a reading aid, not a formal proof; the target engine's actual matching is the final word.
They split understanding from verification: this page breaks an existing regex into human-readable explanations, while regex-tester validates actual matches against test strings. The usual flow is to read the structure here first, then verify with real samples in the tester; whenever the regex changes, re-run both sides.
Huge input can make the tab lag — validate the logic on a trimmed sample before scaling up, and don't resubmit repeatedly mid-run. Catastrophic backtracking is when nested quantifiers retry in a combinatorial explosion on a failed match; it's a runtime performance risk of the regex itself. If you suspect it, run a sample near realistic length and watch whether matching visibly slows down.
Related Tools
Related Articles
Online Regex Explainer: Visualize and Understand Regular Expressions
Learn how to parse and understand regular expressions — lazy quantifiers, lookarounds, named groups, Unicode properties, and how to pair an explainer with a tester.
Regex Not Matching? Troubleshoot These 6 Common Pitfalls
How to troubleshoot when a regex doesn't match or matching fails? This article walks through 6 common pitfalls — greedy quantifiers, missing flags, unescaped special chars, lookaround assertions, newline handling, and Unicode properties — with before/after examples to help you quickly locate regex debugging issues.
Regex Matches Nothing / Greedy .* Swallows Results — How to Fix
Online regex test matches nothing, or greedy .* eats too much, or groups capture nothing? Explains greedy vs lazy, escaping special chars, and anchors — with a step-by-step debug using our regex tester.