Regex Generator
Build a regex from labelled blocks, or infer one from examples that should and should not match — verified against both sets before you're asked to trust it.
Pattern
32 characters/^INV\-\d{4}\-(?<sequence>\d{4})$/gm
Blocks
6- Start of string
- Exact text
- One digit
- Exact text
- One digit
- End of string
This pattern matches, in order:
- the start of the string
- exactly "INV-"
- exactly 4 of a single digit 0-9
- exactly "-"
- exactly 4 of a single digit 0-9, captured as "sequence"
- the end of the string
Try it
2 matchesINV-2024-0001 INV-2025-0042 not-an-invoice
Built and tested in your browser. This tool does not read English descriptions — see the FAQ for why. For debugging an existing pattern, use the Regex Tester; for syntax, the Regex Cheat Sheet.
About the Regex Generator
This regex generator builds a pattern two ways, and neither of them involves describing what you want in English. You can compose from labelled blocks — digits, letters, an email, an ISO date, anchors, quantifiers, capture groups — each with a plain-English line explaining what it matches. Or you can give example strings that should match and strings that should not, and have a pattern inferred from them.
The second mode verifies before it answers. The inferred pattern is run against every example and every counter-example, and if it does not separate the two sets, nothing is emitted — the tool says so and shows you which strings it got wrong. That verification step is the whole difference between this and a guess.
There is no English-to-regex mode, and the reason is worth stating plainly. Describing a pattern in words and getting one back needs a language model, and a regex is a uniquely bad place to accept a plausible-looking wrong answer: it gets pasted into a validator and trusted, and the failures show up as data quietly rejected or quietly let through, months later. A tool that says "I cannot do this" is more useful than one that is right most of the time without telling you which time it is.
Everything is checked live against a test subject as you build it, using the same matching engine as the regex tester on this site.
- Nineteen labelled blocks, from single characters to complete patterns for email, URL, IPv4, UUID, ISO date and hex colour
- Quantifiers with correct grouping — a multi-character block is wrapped before a quantifier is applied to it
- Named and numbered capture groups
- A plain-English explanation, one line per block, in order
- Inference from examples, with the result verified against both the matching and non-matching sets
- Honest failure: when no pattern separates the two sets, none is offered
- Live match highlighting against your own test text
How to use it
- Choose Build from blocks if you know the shape you want, or Infer from examples if you have strings and not a specification.
- In block mode, add blocks in order and set repetition on each. Start with a Start of string anchor unless you deliberately want a partial match.
- Read the numbered explanation under the blocks — it is the pattern in words, and it is where a mistake becomes obvious.
- In inference mode, paste the strings that should match, then — importantly — strings that should not.
- Add counter-examples that are close to the real thing. "INV-24-1" is a much better counter-example than "hello", because it is what a too-loose pattern would wrongly accept.
- Check the result against the Try it box, then copy the pattern as a literal.
Real-world use cases
Backend & full-stack developers
Build a validation pattern for an invoice number, an SKU or an internal ID format from labelled blocks, getting the grouping and escaping right on the first attempt instead of debugging a subtly wrong quantifier later.
QA & test engineers
Infer a pattern from real valid and invalid sample values pulled from test data, with the tool verifying the result actually separates the two sets before you trust it in an assertion.
Data engineers
Derive an extraction pattern for a semi-structured log or export format from real examples, when no format specification exists to build a pattern from directly.
Developers new to regex
Compose a pattern from labelled blocks with a plain-English explanation generated alongside it, learning the correct constructs instead of copy-pasting an unexplained pattern from a forum answer.
API & integration developers
Build a pattern matching a partner's documented ID or reference-number format from its described shape, with live verification against real example values from their documentation.
Examples
A block-built invoice number
Start, exact text INV-, digit ×4, exact text -, digit ×4 captured as sequence, End
/^INV\-\d{4}\-(?<sequence>\d{4})$/The hyphen is escaped even though it is only special inside a character class — escaping unconditionally is always safe and never changes the meaning.
Grouping is applied where a quantifier needs it
exact text ab, one or more
(?:ab)+
Emitting ab+ would repeat only the b. This is the mistake the builder exists to remove, and it is a valid pattern that matches the wrong thing.
Inference from fixed-width examples
INV-2024-0001, INV-2025-0042, INV-2026-9999
/^INV\-\d{4}\-\d{4}$/Every sample is the same length, so each position gets its own class and identical runs collapse into a counted quantifier.
Inference reports failure rather than guessing
matching: 123, 456 — non-matching: 789
The inferred pattern also matches strings you marked as non-matching, so it does not separate the two sets.
No pattern of this kind can accept 123 and 456 while rejecting 789. Saying so is the correct answer.
Common errors
| Message | Cause | Fix |
|---|---|---|
| No single pattern generalises these samples | The examples share no structure the engine can find — they differ in length and in the sequence of character types. | Group the samples by shape and build a pattern per shape, or use block mode. A single regex for genuinely unrelated formats is usually the wrong design anyway. |
| The pattern matches more than it should | No counter-examples were given, so there was nothing to constrain the result against. | Add the near-misses — the strings a slightly-too-loose pattern would wrongly accept. That is what turns inference from a guess into a verified answer. |
| The pattern matches inside a longer string | No anchors. A regex without ^ and $ matches anywhere in the subject. | Add Start of string and End of string blocks. Inferred patterns are anchored automatically; block-built ones are not, and the tool warns when they are missing. |
| The email block rejects a valid address | It is deliberately a shape check, not RFC 5322. The full grammar allows quoted local parts and comments, and a regex implementing it is famously unusable. | Use it for shape and send a confirmation email for existence — which is the only real validation anyway. |
| The generated pattern is slow on long input | Nested quantifiers can backtrack catastrophically. The blocks avoid the worst constructions but cannot prevent every combination. | Anchor the pattern and prefer specific classes to the Anything block. Note that the tester on this site runs on the main thread and a pathological pattern can freeze the tab. |
Frequently asked questions
›Why can I not just describe the pattern in English?
Because that requires a language model, and it would mean giving you a plausible-looking pattern with no guarantee it is correct. A wrong regex is not obviously wrong — it gets pasted into a validator and trusted, and the failure surfaces as data silently rejected or silently accepted much later. The two modes here are deterministic, and the inference mode verifies its answer before offering it.
›How does inference from examples work?
If every example is the same length, each position gets the narrowest character class covering what was seen there, and identical runs collapse into counted quantifiers. Otherwise the samples are reduced to runs of one class each and matched with +. Whichever is produced is then run against every example and counter-example; if it fails either, it is not offered.
›Why do I need counter-examples?
Because without them, the most permissive pattern is always a valid answer. Counter-examples are what make the result mean something, and the useful ones are near-misses — the strings a slightly-too-loose pattern would wrongly accept, not obviously unrelated text.
›Which regex flavour does it generate?
JavaScript, which is what the live tester runs. The constructions used are portable to PCRE, Python and .NET with one exception: named groups are (?<name>...) here, and Python spells them (?P<name>...). The cheat sheet on this site lists the differences.
›Is the pattern I build sent anywhere?
No. Building, inference and matching all happen in your browser, and no request is made.
›Why does it escape characters that do not look special?
Because escaping a non-special character is always safe and never changes what the pattern matches, whereas failing to escape one that is special silently changes the meaning. The hyphen is the usual example: harmless outside a character class, a range operator inside one.
›Can it generate a lookahead or a backreference?
Not from blocks — they cover the constructions with an unambiguous plain-English description, and a lookahead's meaning depends heavily on what surrounds it. Build the pattern here and add the lookahead by hand in the regex tester, where you can see its effect on real input.
›How many examples do I need for reliable inference?
Enough to cover the actual variation in the format — a handful of matching examples that differ in the ways real data differs, plus counter-examples that are close misses rather than obviously unrelated strings. Two or three uniform examples with no counter-examples will usually produce a pattern that is technically correct but far too permissive, because there was nothing to narrow it against.
Last updated