A regex generator with tested patterns and example-based inference
The Regex Generator gives you a working regular expression in two ways. Pick one of 50 carefully written patterns — email, URLs, IPv4/IPv6, dates, UUIDs, PIN codes, PAN, GSTIN, IFSC, Indian/US/UK phone numbers, postcodes, IBAN and more — or paste examples of what should and should not match and let it infer a pattern.
Every pattern is converted for the language you actually use: JavaScript, Python, PHP (PCRE2), Java, C#/.NET or Go (RE2). It writes the right anchors, named-group syntax, flags and string escaping for each, and flags differences such as Python’s Unicode \d or Go’s missing lookahead.
A live test shows which values match as you type, and everything runs in your browser — nothing is uploaded. To dig deeper, copy the pattern into the Regex Tester for highlighting and a token-by-token explanation.
How to use the Regex Generator
- Choose Pattern library, search for “date”, “PAN” or “postcode” and pick a pattern. Its note says what it accepts and what it leaves out.
- Or choose From examples and type values that must match on the left and values that must not match on the right, one per line.
- Set Use the pattern to: validate a whole value (form fields, imports) or find matches inside longer text (logs, documents).
- Pick Groups and tick Ignore case if needed.
- Choose your Language, read the notes, and press Copy pattern or Copy code.
- Type more values into Live test to check edge cases before you ship.
Regex Generator features
50 reviewed patterns
Each has must-match and must-not-match samples that the page re-checks automatically, plus a plain note on its limits — for example, date patterns check the shape but not whether 31 February exists.
Indian formats built in
PIN code, mobile numbers with +91, PAN, GSTIN, IFSC, Aadhaar (format only), vehicle registrations, UPI IDs and lakh–crore amounts such as ₹12,34,567.89.
Inference from examples
A deterministic algorithm finds the separators every example shares, generalises the parts between them into character classes and lengths, and verifies the result against both lists.
Six regex flavours
Correct anchors (\A…\z where $ is lenient), (?P<name>…) for Python and Go, inline (?i) for Go, and properly escaped string literals for every language.
Live test
One value per line in validation mode, or highlighted matches in search mode, using your browser’s regex engine.
How the “from examples” inference works
The algorithm is deterministic. It lists the punctuation and spaces in each must-match example and keeps the longest sequence that appears, in order, in all of them (a longest-common-subsequence of separators). Those characters become fixed text. The pieces between them are compared column by column: if every example has the same layout of runs — say five capitals, four digits, one capital — each run becomes its own class with a length, giving [A-Z]{5}\d{4}[A-Z]. If the layouts differ, the column becomes one class of everything seen there.
It then tests candidates from most general to most specific. With “Generalise lengths” on, it first tries + wherever lengths vary; if that also matches a must-not-match value, it falls back to the exact ranges seen ({2,3}), then to one alternative per layout, and finally to the examples spelled out literally. The panel tells you which step won and which negative example forced it.
Worked example: must match 2024-01-15, 1999-12-31, 2026-10-13; must not match 2024-1-15, 24-01-15, 2024/01/15. The shared separators are the two hyphens, every part is digits of a fixed length, and the result is ^\d{4}-\d{2}-\d{2}$ — all six examples land on the right side.
Limits: inference only knows what your examples show. It cannot learn value ranges (months 01–12), optional parts, or rules like “no double dots”. Add varied examples and must-not-match cases, or start from a library pattern, which encodes that knowledge by hand.
Regex flavours: the differences that matter
| Topic | JavaScript | Python | PHP / Java / .NET | Go (RE2) |
|---|---|---|---|---|
| Whole-value anchors | ^…$ | \A…\Z or fullmatch | \A…\z | ^…$ |
| Named group | (?<y>…) | (?P<y>…) | (?<y>…) | (?P<y>…) |
\d matches | ASCII 0–9 | any Unicode digit | ASCII (Java, PCRE) · Unicode (.NET) | ASCII 0–9 |
| Lookahead / lookbehind | Yes | Yes (fixed-width lookbehind) | Yes | No |
| Backtracking risk | Yes | Yes | Yes | No — linear time |
| Ignore case | i flag | re.IGNORECASE | /i, CASE_INSENSITIVE, IgnoreCase | (?i) prefix |
Tips for regexes that hold up in production
- Validate whole values with anchors. Without them,
\d{6}happily “validates”abc1234567xyz. - Use a regex for shape and code for meaning: check a card’s Luhn digit with the Credit Card Validator, or an IBAN’s MOD-97 with the IBAN Validator.
- For email, the only true test is sending a message; the Email Validator catches common typos first.
- Avoid nested quantifiers such as
(a+)+on untrusted input — they can backtrack for minutes in every flavour except Go.
Regex Generator FAQ
How do I generate a regex from examples?
Switch to “From examples”, list values that must match on the left and values that must not match on the right. The regex generator finds the shared separators, turns the parts between them into character classes and lengths, and checks the result against both lists. Add more varied examples if the pattern is too narrow.
Is the email regex RFC 5322 compliant?
No, on purpose. RFC 5322 allows quoted names, comments and IP-address domains that almost no real form accepts, and a fully compliant regex is thousands of characters long. The practical pattern accepts the addresses people actually use and rejects common typos such as double dots.
Why does the Python version use [0-9] instead of \d?
In Python 3, \d in a text pattern matches any Unicode decimal digit, including Devanagari ३ and Arabic-Indic ٣, so a “digits only” check would let them through. [0-9] means ASCII digits in every language. .NET behaves the same way.
Why do some patterns use \A and \z instead of ^ and $?
In Python, PHP, Java and .NET, $ also matches just before a trailing newline, so "123\n" passes a ^\d+$ check. \A and \z (\Z in Python) anchor to the true start and end. JavaScript and Go have no such gap, so they keep ^…$.
Can it check that a PAN, GSTIN or Aadhaar number is real?
No regex can. These patterns check the official format; the last character of a PAN and GSTIN and the final Aadhaar digit are checksums, and only the issuing authority can confirm a number exists. Treat Aadhaar numbers as sensitive personal data.
Can I open the pattern in the Regex Tester?
Yes. “Copy & open Regex Tester” copies the JavaScript version and opens the tester in a new tab; paste it into the pattern box to see highlighted matches and an explanation of each token.