Regex Generator

About the Regex Generator

Regular expressions are read far more often than they are written, which is exactly backwards from how they are taught. Most people writing one have not written one for six months, know precisely what they want to match, and will spend twenty minutes rediscovering whether the flavour in front of them supports lookbehind.

Describe the match in English here and the expression comes back, along with the two things that decide whether it works in practice: whether it is anchored, and whether it is meant to validate a whole string or find matches inside one. Getting that pair wrong is the most common way a correct-looking pattern fails in production, and it fails quietly — an unanchored validation pattern accepts anything with a valid substring buried in it.

The flavour setting is not a formality. Go's RE2 has no backreferences and no lookaround of any kind, by design, because it guarantees linear-time matching. POSIX, which is what grep -E gives you, has no shorthand classes and no lazy quantifiers. If your description needs a feature the chosen flavour cannot express, this page says so plainly and gives the nearest thing that works, with its limitation named, rather than handing over a pattern that fails on the target platform.

Readability is preferred over cleverness throughout: character classes rather than long alternations, no nested quantifiers that can backtrack catastrophically, and a recommendation to use two simple expressions where one dense one would be worse. That last suggestion is offered surprisingly often and is almost always right.

The breakdown explains the pattern component by component, in the order the components appear. The examples list strings it matches and, more usefully, near-misses it rejects — chosen to be the ones a careless pattern would wrongly accept, which is what you want to see before trusting it.

Then test it. There is a regex tester on this site that runs entirely on your own machine, and no generated pattern should be deployed without going through something like it.

How to use it

1. 1Describe what should match, in ordinary words. Mention the cases that should not match too.
2. 2Pick the flavour you will use it in — this genuinely changes what is possible, not only the syntax.
3. 3Read the line about anchoring before anything else. It decides whether the pattern validates or searches.
4. 4Check the near-misses in the “does not match” list against your real data.
5. 5Paste it into the regex tester here and run it over real examples before you ship it.

Questions

Can I trust the expression without testing it?

No, and that is true of hand-written ones too. A pattern that matches every example you thought of can still match things you did not, and validation bugs almost always take that shape. The tester on this site runs on your own machine and takes a minute.

Are the example strings verified?

Yes, by your browser rather than by the model. Every string in the two lists is run against the generated expression using the engine already in this tab, and anything that behaves differently from its label is reported to you as a contradiction. This exists because it caught one: an early answer here filed a valid postcode under the strings it rejects. What the check proves is narrow but real — that the expression and its own examples agree. It cannot tell you the expression is the one you meant to ask for, and it stays quiet on flavours whose syntax this engine would misread, such as POSIX bracket expressions.

Why does the Go option sometimes refuse part of my description?

Because Go's regexp package implements RE2, which deliberately omits backreferences and lookaround to guarantee that matching cannot blow up on a crafted input. That is a real trade-off rather than a missing feature, so the honest answer is to say the expression cannot be written there, and give the nearest one that can.

Should I use a regex to validate email addresses?

Usually not. The specification permits addresses far stranger than any reasonable pattern accepts, and the strict expressions are unreadable and still wrong. Check for an at sign with something either side, then send a confirmation email — which is the only test that establishes the thing you actually care about.

What does catastrophic backtracking mean?

A pattern with nested quantifiers can take exponential time on an input that nearly matches, hanging the process. It is a real denial-of-service route when patterns run against user input. The expressions here avoid the constructs that cause it, and the RE2 flavour cannot express them at all.