Regex Visualizer
Visual pattern diagram with live match highlighting and capture group annotations.
Pattern Diagram
Capture Groups — 3 matches
| # | Full match | Group 1 | Group 2 | Group 3 |
|---|---|---|---|---|
| 1 | 2024-01-15 | 2024 | 01 | 15 |
| 2 | 2024-12-31 | 2024 | 12 | 31 |
| 3 | 2024-03-08 | 2024 | 03 | 08 |
Regex Visualizer — Pattern Diagram & Live Match Highlighting
Paste any JavaScript regular expression and instantly see a visual pattern diagram, live match highlighting across your test string, and a capture group table — all updating in real time as you type. Unlike a plain regex tester, the Regex Visualizer breaks each token in your pattern into a labelled, colour-coded node: literals in blue, escape sequences in violet, character classes in amber, anchors in green, and capture groups in bordered boxes numbered #1, #2, …
Every capture group gets a unique colour both in the diagram and in the highlighted test string, so you can see at a glance exactly which part of the pattern captured which substring. The groups table lists every match with its captured substrings in separate columns — ideal for extracting structured data from log lines, CSV rows, or API responses. Alternation branches (a|b|c) are rendered vertically in the diagram so you can read each branch independently. Quantifiers (+, *, {n,m}) appear as a teal annotation under the token they repeat.
All processing is 100% client-side — your patterns and test data never leave your browser, making it safe to debug against production log files or sensitive records. The URL hash stores your pattern, flags, and test string, so you can share a permalink with teammates, paste it into a PR comment, or bookmark a pattern you want to revisit. Pair it with the RegExp Tester for quick match iteration, or use Find & Replace to apply your debugged pattern to a text corpus.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Seeing a pattern's structure as a diagram rather than a string.
- Understanding where a capture group begins and ends.
- Working out why a pattern matches more than intended.
- Explaining a pattern to someone in a review.
- Learning regex structure by visualising your own patterns.
How it works in practice
A worked example
Somebody else's validation pattern is rejecting an address that looks fine, and reading the pattern left to right has not explained why.
^[\w.+-]+@[\w-]+\.[\w.-]+$
A railroad diagram, left to right: ^ start of string one-or-more of [word char . + -] @ one-or-more of [word char -] . (escaped, a literal dot) one-or-more of [word char . -] $ end of string
Laid out as a track, the shape of the pattern is the answer. The two anchors at the ends are what make this a whole-string test rather than a search, the escaped dot in the middle is a literal and not the any-character wildcard, and each bracketed group is a character class with its own quantifier hanging off it. Reading the same expression as a string of punctuation hides all three of those; reading it as a sequence of boxes makes the missing piece — no dot allowed before the at sign, for instance — visible without tracing anything.
The edge case that catches people
The diagram comes from this page's own parser, which is the honest limitation and worth knowing. It models the constructs it knows about and renders anything else as an opaque box carrying the raw text, so an exotic lookbehind or a Unicode property escape will appear as a node without being explained. That is deliberate — a diagram that quietly mis-draws a construct would be worse than one that admits it is passing the text through — but it means an unadorned box is a prompt to check the specification rather than a claim that nothing is happening there.
When not to use this tool
A picture of a pattern is not a test of a pattern. It shows what the expression says and cannot show what it does to your data, so a diagram that looks right and a pattern that matches the wrong thing are entirely compatible — the tester next door is where a pattern meets real input. Use the diagram to understand an expression somebody else wrote or to explain one in review, and use actual strings, including the ones that should fail, to decide whether it is correct.
Frequently Asked Questions
- What does visualising a pattern actually show?
- The structure — which parts are alternatives, which repeat, and how groups nest. That is exactly the information dense syntax hides, and it is usually where a misunderstanding lives.
- Why does my pattern match more than I expect?
- Most often because alternation binds loosely: `^a|b$` means "starts with a, or ends with b", not "starts with a or b and ends there". Grouping the alternation is the fix.
- How do I test a pattern properly?
- With cases that should NOT match as well as cases that should. A pattern validated only on positive examples usually turns out to accept far more than intended.
- Is a regex the right tool for parsing HTML or JSON?
- No. Both are recursive and regular expressions are not, so any pattern handles a subset and fails on legal input. Extracting one simple attribute is fine; parsing is not.
Common errors and gotchas
- Trusting the diagram over testing, since a structure can be right and the pattern still wrong for your input.
- Assuming one flavour, where the diagram may show a construct your engine does not support.
- Overlooking flags, which change anchors and the dot without appearing in the structure.
- Missing catastrophic backtracking, which a structural view does not reveal.
- Reading a group as capturing when it is non-capturing, which changes every index after it.