Generador de códigos QR

Building a regex from examples instead of from scratch

Writing a regular expression by hand means holding the whole pattern in your head — anchors, character classes, quantifiers, escaping — before you've matched anything. This tool flips that around: you give it real strings that should match and, optionally, strings that should not, and it infers a pattern for you. It then immediately runs that pattern against every example so you can see which pass and which fail. The goal isn't to replace learning regex; it's to give you a correct, tested starting point you can refine. This is a distinct task from looking up regex syntax — here the input is data, and the output is the pattern.

How the inference works

The generator looks for structure shared across your positive examples and builds the pattern in four moves:

• Common prefix and suffix. It finds the longest leading and trailing text that all your examples share and pins them in place literally. If every example starts with INV- and ends with .pdf, those become fixed anchors.
• Generalizing the middle. Whatever varies between the prefix and suffix is the "core." Runs of digits become \d+ and runs of letters become [a-zA-Z]+, so the pattern matches the shape of the data rather than the exact characters.
• Alternation when middles differ. If the variable parts aren't all the same shape, the tool wraps the distinct options in a non-capturing group with |, like (?:\d+|[a-zA-Z]+).
• Anchoring. The whole pattern is wrapped in ^...$ so it must match the entire string, not just a fragment.

Special characters in the fixed parts (dots, dashes, slashes) are escaped automatically, so a literal . in file.txt won't be misread as "any character."

A worked example

Enter three positive examples: hello123, world456, test789. There's no shared prefix or suffix, so the whole string is the core. Each is a run of letters followed by a run of digits, so letters generalize to [a-zA-Z]+ and digits to \d+, producing ^[a-zA-Z]+\d+$. The tool tests it: all three positives show a green check. Now add a negative example 123xyz — digits first, then letters. Because the pattern requires letters before digits, 123xyz correctly fails to match and shows a green check in the negatives list too (a negative passing means it was correctly rejected).

A second case shows prefixes at work. Give it order-1, order-2, order-99: the shared prefix order- is detected and escaped, the varying tail is all digits, and you get ^order\-\d+$.

How to read the results

Each example gets a colored row. In the positives list, a green check means the pattern matched (good) and a red cross means it didn't (the pattern is too strict). In the negatives list it's inverted: green means the pattern correctly rejected the string, red means the pattern wrongly matched something it shouldn't (too loose). You can also type any string into the live test box to get an instant MATCH / NO MATCH badge. The aim is all-green in both lists — that's a pattern that accepts everything you want and rejects everything you don't.

Practical tips for better patterns

• Give varied positives. Three near-identical examples teach the tool almost nothing. Include short and long cases, different counts of digits, and edge cases so the inferred pattern generalizes correctly.
• Always add negatives. Negatives are how you catch an over-broad pattern. If a string you want excluded shows red in the negatives list, your examples need refining.
• Watch the + quantifier. \d+ means "one or more digits" of any length, so it matches a 2-digit and a 20-digit number alike. If you need an exact length, edit the result to \d{4} by hand.
• Refine, don't just accept. The output is a clean draft. Tighten character classes ([a-z] vs [a-zA-Z]), add length bounds, or relax the anchors depending on whether you're matching whole strings or searching within text.

Common mistakes

• Expecting it to mind-read intent. The tool sees character shapes, not meaning. From 2024 it infers \d+, not "a four-digit year" — add the constraint yourself if it matters.
• Forgetting the anchors. The generated pattern uses ^...$ for full-string matching. If you'll use it to find matches inside longer text, you may need to drop the anchors.
• Too few examples. A single positive produces a pattern fitted tightly to that one string; supply several so the generalization is meaningful.

Runs entirely in your browser

Pattern generation and all testing happen locally in JavaScript using the browser's built-in regex engine — your example strings are never uploaded. You can paste sensitive sample data, and the tool keeps working offline. Always test the final pattern in the language where you'll deploy it, since regex flavors differ slightly between JavaScript, Python, PCRE, and others.