Regex Generator

How the Regex Generator works

Regex generator: from a description to a working pattern

A regular expression is a tiny program for matching text, and it is one of the few tools that turns up in almost every language, editor, database and log system you will ever touch. The trouble is the syntax. A correct IPv4 pattern runs to more than 80 characters of brackets, pipes and backslashes, and a single missing escape turns "a literal dot" into "any character". This generator starts from what you want to match, picks a tested pattern, and quotes it correctly for the language you are pasting into, so the only thing left to do is check it against your own data.

Why it matters. Most regex bugs are not dramatic. A validation rule that rejects o'brien@example.ie loses a customer quietly. A log search that matches 10.0.0.1 inside 110.0.0.15 inflates a count that someone then puts in a report. A pattern with nested quantifiers can take seconds on a hostile input, which is how Cloudflare's global outage of July 2019 started: one expression in a firewall rule backtracked catastrophically and pinned CPUs worldwide. Starting from a known shape, and testing it on real lines, removes most of that risk.

Where generated patterns are used

• Form validation. HTML's pattern attribute takes a regex and anchors it to the whole value automatically. Email, postcode, username and slug rules are the usual suspects.
• Log and data searches. grep -E, Splunk, Elasticsearch, Google Sheets' REGEXMATCH and BigQuery's REGEXP_CONTAINS all take a pattern for pulling IP addresses, UUIDs or dates out of free text.
• Editors and IDEs. VS Code, JetBrains and Sublime Text accept regexes in find and replace, which is the fastest way to reformat a thousand dates from DD/MM/YYYY to ISO 8601.
• Routing and config. Nginx location ~ blocks, Apache rewrite rules and CI path filters are regexes too, and a missing anchor there changes which requests match.

How to read the result

The output box holds the bare pattern. Below it:

• Matches says in plain words what the pattern accepts, for example "four octets of 0 to 255 separated by dots, no leading zeros". Read this first: if the description is not what you meant, the pattern is not either.
• JavaScript gives a literal such as /^(?:\d{5}(?:-\d{4})?)$/, with forward slashes escaped and the g flag added when the scope is Anywhere in text.
• Python gives a raw string, r"...", so backslashes reach the re module untouched.
• PHP gives a single-quoted string with / delimiters for preg_match.
• Go gives a backtick raw string for regexp.MustCompile. Go uses RE2, which has no lookaheads, so the Strong password preset will not compile there; every other preset will.

Paste test lines into the input, one per line, and the table shows each line with Match or No match and the text that matched. With Anywhere in text, several hits on one line are listed, separated by commas.

Whole line or anywhere in text

The scope choice is the single most important setting. Whole line wraps the pattern as ^(?:...)$, so the entire input must fit; use it for validating a form field. Anywhere in text leaves it bare and adds the global flag; use it for finding every email address in a pasted document. The non-capturing group matters: without it, ^a|b$ means "starts with a, or ends with b", which is a classic source of validation holes.

Generalise from my samples

Choose this option and paste examples that share one shape. The generator splits each line into runs of digits, runs of letters, whitespace and single punctuation marks, checks that every line has the same sequence, and then widens each run to cover all the samples. Given AB-1234 and CD-567, it produces [A-Z]{2}-\d{3,4}: two capitals, a literal hyphen, then three or four digits. Letter classes stay upper-case, lower-case or mixed depending on what the samples contained. If the lines have different shapes, for example one with a space and one without, it says it cannot generalise; split the samples into groups that share a layout and generate one pattern for each.

Tips and pitfalls

• Format is not validity. The ISO date pattern accepts 2026-02-31, and the credit card pattern accepts any 13 to 19 digits. Check dates with a real date parser and card numbers with the Luhn checksum.
• Email is a compromise. RFC 5322 allows quoted local parts and comments that no practical regex handles. The preset covers the addresses people actually type; the only true test is sending a confirmation message. The email validator explains what each part of an address may contain.
• Phone numbers are local. The UK and US presets expect those formats. For storage, normalise to E.164, which is + followed by at most 15 digits under the ITU-T standard.
• Escape user input. If part of the pattern comes from a user, escape it first with the string escaper, or a stray . or ( will change the meaning or throw an error.
• Flavours differ. \d matches Arabic-Indic and other Unicode digits in Python 3 and .NET but only 0 to 9 in JavaScript without the u flag. Test in the engine you will run.

To step through a pattern against larger text, with flags and capture groups highlighted, open the regex tester. For URLs and UUIDs that need more than a format check, the URL validator and UUID validator parse the value properly.

Related tools