Regex Generator
Describe what a pattern should (and should not) match, and get a regex prompt with real test examples and a plain-language breakdown.
Writing regular expressions from scratch is genuinely error-prone even for experienced developers, since small syntax differences produce silently wrong matches rather than errors. This tool converts a plain description of the pattern you want to match into a working regular expression, with an explanation of what each part does.
How to use it
In plain language -- what should and shouldn't match, ideally with a couple of real examples.
A should-match and a should-not-match example both meaningfully improve accuracy.
Includes a plain-language breakdown of what each part of the pattern does.
Tips for better results
- Always provide at least one negative example. A pattern that matches your positive example can still be too broad without a negative one to constrain it.
- Specify the regex flavor if it matters. Different languages have real syntax differences in some edge cases -- state which you need if unsure.
- Test against a larger sample before deploying. A pattern that works on your few examples can still fail on inputs you didn't think to test.
Example output
“Description: match US phone numbers with optional parentheses and dashes. Produces the pattern plus a breakdown explaining what each group and quantifier does.”
TL;DR
A regular expression that looks right can still fail on real input in ways that are hard to spot just by reading the pattern — an email regex that matches the common case but breaks on a plus-addressed Gmail address, or a phone-number pattern that accepts one too many digits.
Why test examples matter more than the description
Describing a pattern in words is inherently ambiguous — “a valid email address” means something different depending on whether you care about plus-addressing, subdomains, or unusual but technically valid TLDs. Providing concrete strings that should and should not match removes that ambiguity entirely, and more importantly, gives the model something to actually check its own answer against before finalizing it, rather than producing a regex that merely looks plausible.
This matters because regex mistakes are usually invisible until they hit the one edge case they were not built for — a validation pattern that is too loose lets bad data through silently, and one that is too strict rejects valid input and generates support tickets from confused users. Testing against explicit examples before the pattern ships is far cheaper than discovering the gap in production.
Describing US phone number matching with three format examples and two invalid examples, JavaScript flavor, produces:
“Write a JavaScript-flavor regular expression that matches: US phone numbers in several common formats.
It should match strings like:
– (555) 123-4567
– 555-123-4567
– 555.123.4567
It should NOT match strings like:
– 123-4567
– 555-123-45678
Provide the pattern on its own line first…
Test the pattern mentally against every example above…”
That gives the model concrete pass and fail cases to check the pattern against before finalizing it.
Using this across ChatGPT, Claude, and Gemini
All three models can write regex reasonably well, but actually testing the generated pattern against your real examples afterward (in an online regex tester, or directly in your code) remains worth doing regardless of which model wrote it — regex is one of the areas where a subtly wrong pattern can look completely correct on a quick read. Claude tends to walk through the match/no-match examples most explicitly when asked to verify its own answer.
FAQ
Do I need both match and non-match examples?
Match examples alone still help, but non-match examples are what catch an overly permissive pattern — for anything validating user input, include at least one of each.
What is the difference between the regex flavors listed?
They differ in details like lookahead/lookbehind support and named group syntax — picking the flavor matching your actual programming language avoids a pattern that looks right but fails to compile.
Can this generate a regex for a genuinely complex pattern, like parsing a whole log line?
Yes, though complex patterns benefit even more from real examples — provide several realistic log line samples rather than just one to catch formatting variations.
Should I trust a generated regex without testing it myself?
No — always run it against a real, larger sample of your actual data before relying on it, especially for anything validating or filtering user-facing input.
