Regular expressions are powerful and unforgiving — one stray quantifier and the whole pattern misbehaves. Instead of fighting the syntax, describe what you want to match in plain English and let your own OpenAI or Anthropic key build the pattern, explain it, and check it against your test strings, all in your browser.
How it works
Pick a provider and model, paste your API key, and choose the regex flavour your engine uses. Describe the match requirement in plain language, then optionally paste test strings one per line. The tool builds a prompt that asks for the simplest correct pattern, a part-by-part breakdown of what each piece does, and an explicit match-or-not verdict for every test string you supplied. It sends one direct request to the provider and returns the full result to copy.
For Anthropic, the request includes the official direct-browser-access header so it works straight from the page.
Why flavour matters — and the differences you need to know
The same pattern can behave differently or fail to compile entirely depending on which engine runs it. The key distinctions:
JavaScript: Uses the RegExp object. Named capture groups supported ((?<name>...)). Lookbehind added in ES2018 (not available in all older environments). No possessive quantifiers. The g flag changes how exec iterates, which trips up many developers.
Python (re module): Supports lookahead and lookbehind. Named groups with (?P<name>...) syntax (different from other engines). re.compile() + re.fullmatch() is the idiomatic pattern for whole-string matching.
PCRE (PHP, Nginx, many tools): Full-featured — possessive quantifiers, atomic groups, conditional patterns. The most permissive common engine. Patterns written for PCRE may not compile elsewhere.
Java: Similar to PCRE but with Java string escaping quirks (every \ must be \\ in a string literal). Lookbehind must have fixed or bounded width.
Go (RE2): The most restrictive. No backreferences, no lookahead, no lookbehind. Designed for linear-time guarantees, which eliminates catastrophic backtracking at the cost of expressiveness. Many patterns from other engines need rethinking for RE2.
.NET: Supports balancing groups and other advanced features not found elsewhere. If you’re matching nested structures, .NET is the only standard engine that can do it natively.
Selecting the correct flavour before generating is important — the model will produce a valid pattern for the engine you chose, not a generic one that may fail to compile.
Writing a good description
Be precise about boundaries and optional parts. “A UK postcode with an optional space, case-insensitive” gives the model everything it needs; “match postcodes” leaves too much open. Mention anchoring if it matters — whether the pattern should match the whole string or just find occurrences inside it. Listing a couple of strings that should not match is often more useful than the ones that should, because it pins down the edges of the pattern.
Notes and limits
The model defaults to readable, well-anchored patterns and is told to avoid constructs that cause catastrophic backtracking, but no generator is infallible. Always run the pattern through a dedicated regex tester with your real inputs, and watch out for engine differences — a pattern that works in JavaScript may need adjusting for Go’s RE2 or for grep. Treat the explanation as a learning aid: if you understand each part, you will catch the mistakes the model misses.