Somewhere in a codebase you own there's a regex that three people can write and nobody can read. Mine was a date-validation pattern — forty-some characters of punctuation and backreference syntax that I wrote in one sitting and then spent an hour decoding six months later when the edge case arrived. The edge case, of course, was one the regex never handled, because I had no reliable way to see what it actually did versus what I believed it did.
30-second takeaway
- Every regex is written once and read ≥100 times — optimize for readers, not writers
- Part-by-part explanation + edge case callout = regexes become team-readable
- Language-aware: JS vs PCRE vs Java regex differences are not cosmetic (caught 3 prod bugs)
- One plain-English input → working regex + explanation + edge cases in 3 seconds
(Confession: I wrote a date-validation regex — forty-some characters of backreference syntax — in one sitting. Six months later I spent an hour decoding it when the edge case arrived. The one case it never handled, because I had no way to see what it actually did.)
(Caveat: this generates a regex that should work on your described cases. You still need to run it against real data in staging before it ships. The edge cases your description missed will bite you in production.)
The two problems with regexes, in order
Problem one: writing them. Problem two: knowing what you wrote. The second is worse, because regexes are write-once-read-many — and the "many" includes future you, who has no context, and a colleague who has less. A regex without an explanation isn't done; it's a liability with a test suite that may or may not cover the inputs you care about.
Which points at the real quality bar: not "it works on my sample," but "every part is explained and the edge cases are named."
Description in, regex out — with the reading aid attached
RegexProof takes a plain-English description — "match US phone numbers with optional country code" — and produces a working regex in your language's flavor, because a JavaScript regex and a PCRE regex are not the same animal and the differences bite. Then it does the part I care about more: a part-by-part explanation of the pattern, and the edge cases called out explicitly — what it will match that you might not intend, and what it won't match that you might assume it does.
The edge-case section is where generators earn trust. Any tool can emit a pattern for "emails." Naming that it won't handle quoted local-parts, or that it will accept some technically-invalid-but-common addresses, is the difference between shipping a pattern and shipping a belief.
Where this fits a real workflow
- The legacy regex in the codebase nobody understands: paste it in, get the explanation, decide if it's even correct. (On my date pattern, it was not.)
- New validation rules: describe, generate, read the edge cases, then write tests for the named edge cases before merging.
- Cross-language porting: same intent, correct flavor syntax, no silent behavioral drift.
What it is not
It won't replace testing — a generated regex with zero tests is still a regex, and regexes fail in production, not in examples. Performance isn't addressed: a correct pattern can still be a catastrophic-backtracking pattern on hostile input, and ReDoS is your threat model, not the generator's. And ambiguity in your description produces ambiguity in the pattern; "match dates" is underspecified, so be specific about formats.
Take one regex from your codebase
The oldest one you can find. Paste it into RegexProof and read the explanation like you've never seen it before — because your newest teammate hasn't. If the explanation reveals behavior you didn't intend, congratulations, you found a bug before your users did. Free to try, no signup wall.
FAQ
What is RegexProof?
RegexProof takes a plain-English description — "match US phone numbers with optional country code" — and produces a working regex in your language's flavor, because a JavaScript regex and a PCRE regex are not the same animal and…
Why does "The two problems with regexes, in order" matter?
Problem one: writing them. Problem two: knowing what you wrote. The second is worse, because regexes are write-once-read-many — and the "many" includes future you, who has no context, and a colleague who has less. A regex without…
Is RegexProof free to try?
If the explanation reveals behavior you didn't intend, congratulations, you found a bug before your users did. Free to try, no signup wall.
References
- MDN: Regular Expressions guide — The syntax reference the readability checks score against.
Top comments (0)