Regex Pattern Builder
The Regex Pattern Builder translates a plain-language description of what you want to match into a working regular expression with a step-by-step breakdown of every component. It eliminates the trial-and-error cycle of writing regex by producing a pattern, explaining why it works, and providing test cases that prove it handles both expected matches and common edge cases.
Developers of all experience levels use this template when they need to validate input formats, extract data from strings, build search patterns, or write text transformations. It is especially valuable for developers who write regex infrequently and forget the syntax between uses, or for complex patterns where even experienced developers benefit from a second set of eyes on edge cases.
The prompt requires you to specify your programming language or regex flavor because syntax varies significantly (Python's re module, JavaScript's regex engine, PCRE, POSIX). It also asks for examples of strings that should and should not match, which grounds the AI in concrete test cases rather than abstract rules. The output includes both the regex pattern and a character-by-character explanation, so you can understand and maintain the pattern rather than treating it as a black box.
This prompt is just the starting point
Score it with AI, optimize it with one click, track versions, and build your prompt library.
The Prompt
Build a regular expression pattern for the following requirement: **What I Want to Match**: [DESCRIBE IN PLAIN LANGUAGE, e.g., "Email addresses that end with .edu or .ac.uk", "Phone numbers in US format with or without country code", "All dates in YYYY-MM-DD format where the year is between 2000 and 2029"] **Programming Language / Regex Flavor**: [Python / JavaScript / Java / PHP (PCRE) / Go / Ruby / .NET / POSIX / other] **Examples That SHOULD Match**: ``` [LIST 3-5 STRINGS THAT SHOULD BE MATCHED] ``` **Examples That Should NOT Match**: ``` [LIST 3-5 STRINGS THAT SHOULD BE REJECTED] ``` **Additional Requirements**: - [e.g., "Case insensitive", "Must match the entire string (not partial)", "Should capture the domain part in a named group", "Must work in a multiline context"] Provide your response in this format: 1. **The Pattern**: The complete regex, ready to copy-paste into code. 2. **Pattern Breakdown**: Explain each component of the regex on its own line: - `^` - Start of string anchor - `[A-Za-z]` - Matches any letter... - *(continue for every meaningful component)* 3. **Code Example**: A working code snippet in the specified language that demonstrates the pattern in use (matching, extracting groups, or replacing). 4. **Test Results Table**: A table showing each example string (both should-match and should-not-match), the expected result (match/no match), and the actual result from the pattern. 5. **Edge Cases to Watch**: List 3-5 edge cases that might trip up this pattern in production (e.g., Unicode characters, empty strings, extremely long input, line breaks) and whether the pattern handles them. If it does not, provide a modified pattern that does. 6. **Performance Note**: If the pattern could suffer from catastrophic backtracking on certain inputs, explain why and provide a safer alternative.
Usage Tips
- Provide concrete examples, not just descriptions: "Phone numbers" is ambiguous. "(555) 123-4567, 555-123-4567, +1 555 123 4567" is concrete. The more examples you provide, the more precisely the AI can calibrate the pattern.
- Always specify the regex flavor: JavaScript does not support lookbehinds in older environments. Python uses
rewith different flags than PCRE. Go does not support backreferences. The right pattern for one language may fail in another. - Test the edge cases yourself: The AI will flag likely edge cases, but always test the pattern against your actual data before deploying to production. Regex is one area where even small oversights cause real bugs.
- Ask for the simpler version first: If you need a complex pattern, start by asking for a basic version that handles 90% of cases, then add edge case handling incrementally. This makes the pattern easier to understand and debug.
- Use named groups for extraction: If you need to pull specific parts out of a match (e.g., the area code from a phone number), mention this in your requirements. Named groups make the resulting code much more readable than positional group references.
Get more from this prompt
Save it, score it with AI, optimize it, and track every version. Free to start.