Regex visualizer.

How it works

The regex is parsed into an AST using regexpp — the same parser ESLint uses internally. Each AST node is mapped to a railroad-diagram primitive (Sequence, Choice, Optional, ZeroOrMore, OneOrMore, Group, Terminal) and the SVG is rendered using Tab Atkins' railroad-diagrams library — the same one used in W3C specs.

The plain-English panel walks the same AST and emits one phrase per node, joined with "then" for sequences and "or" for alternations. Quantifiers are described by the actual {min, max, greedy} values rather than just the surface syntax — so x{2,5} reads as "between 2 and 5 of x" and x*? reads as "zero or more (lazy) of x".

The live tester compiles the source with new RegExp(source, flags) and runs matchAll when the g flag is set; matches are highlighted inline in the test input. The diagram colour-codes built-in groups (terracotta), capture groups (dashed border), and assertions like ^ / $ / \b (green).

Everything runs client-side; the two libraries are loaded once from a CDN as ES modules.

Planned

• Capture group preview — for each match, show what each numbered or named group captured, lined up with the diagram.
• Substitution mode — second input for a replacement string (with $1 / $<name> support), see the result live.
• Common patterns library — vetted regexes for email, URL, semver, UUID, ISO date, etc., with notes on when each is the right call (and when "use a real parser" is the right call instead).
• ReDoS detector — flag patterns vulnerable to catastrophic backtracking (nested quantifiers, alternation with overlap), with a benchmark run on a payload designed to trigger them.
• Dialect support — toggle between JavaScript / PCRE / Python / Go regex dialects, with warnings about features that don't translate.