Describe it in English, get a working regex
Regular expressions are powerful but fiddly to write by hand. Describe the pattern you want in plain language, bring your own OpenAI key, and this tool generates a JavaScript regex — then tests it live against your sample strings so you can confirm it actually matches what you meant before you ship it.
How it works
When you submit a description, the tool sends a focused prompt to the OpenAI
Chat Completions API asking for a single JavaScript regular expression and
nothing else. It extracts the pattern from the response and compiles it with the
browser’s native RegExp. Your sample strings are then matched locally —
the tool highlights every match and shows which substrings were captured.
Because generation and testing are separated, you get the best of both: the model handles the hard part of writing the pattern, while your own examples provide ground truth for verifying it. If a sample matches that shouldn’t, refine the description and regenerate.
Tips for better results
- Give examples in your description. “Matches dates like 2026-06-05 but not 06/05/2026” produces a tighter pattern than “matches dates”.
- List what should not match — negative examples sharpen the regex dramatically.
- Add edge cases to your samples (empty strings, extra whitespace, mixed case) so the live test exposes gaps.
- Verify in your target language. JavaScript regex is close to PCRE but features like lookbehind support vary across engines.
What makes a good description for AI regex generation
The model works best when your description combines three elements: what you want to match, a concrete example of a match, and at least one example of what should not match. Compare these two prompts for the same goal:
Vague: “Match UK phone numbers”
Specific: “Match UK phone numbers like 07700 900123, +44 7700 900123, or 0207-123-4567 but not US formats like (555) 123-4567 or international ones with country codes other than 44”
The specific version gives the model format anchors (spacing variations, +44 prefix, - separators) and an explicit exclusion (US format). The generated regex will cover significantly more real-world variation.
If you are matching something with a well-known specification (email addresses, IBANs, credit cards, ISBN numbers, postcodes), name it by its standard name — “an RFC 5322 email address” or “a UK postcode in the standard format” gives the model a precise target to aim at.
Common descriptions and what to expect
| Description | What tends to work | Watch for |
|---|---|---|
| Email addresses | Good patterns for standard formats | RFC 5322 is extremely complex; simple heuristics miss edge cases |
| UK postcodes | Accurate PCRE-style pattern | Always test with real postcode samples from different regions |
| ISO dates (YYYY-MM-DD) | Very reliable | Adding range checks (month 01-12) requires a more complex alternation |
| Credit card numbers (16-digit) | Gets the digit structure right | Luhn checksum validation needs code, not just regex |
| IP addresses (IPv4) | Basic pattern works | Validating 0-255 per octet requires alternation or a separate check |
For highly structured data formats with well-defined specs (IBANs, VINs, NI numbers), copy a few real examples and one or two malformed examples into your test strings immediately after generating — this is the fastest way to find gaps.
After you have your regex
The live test confirms the pattern on your samples, but production data is messier than test samples. A few things to check before shipping:
- Test with the minimum possible match (an email with one character before the
@) and the maximum (a very long domain) - Test with Unicode input if your system accepts non-ASCII characters
- Check whether the pattern should be anchored (
^...$for full-string matching) or unanchored (for finding a match within a larger text) - Confirm the flags — global (
g) to find all matches, case-insensitive (i) if needed