Prompt Details
Model
Chat - (gpt-5.6)
Token size
342
Example input
[WHAT_TO_MATCH]: valid email addresses
[MUST_MATCH]: test@site.com, a.b@example.co.uk
[MUST_NOT_MATCH]: plain text, @nope.com, user@, a@b
[REGEX_FLAVOR]: JavaScript
[EXTRA_RULES]: case-insensitive, match the whole string
Example output
1. REGEX
regex
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}$/i
This is ready to use in JavaScript as a regular expression literal.
2. HOW IT WORKS
Pattern:
regex
^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}$
with the i flag for case-insensitive matching.
Part Meaning
^ Start of the string. Ensures we match the whole input, not just part of it.
[A-Z0-9._%+-]+ Local part (before @). Allows one or more letters, digits, ., _, %, +, and -.
@ Literal @ separator.
[A-Z0-9.-]+ Domain name. Allows letters, digits, dots, and hyphens.
\. A literal dot before the top-level domain.
[A-Z]{2,} Top-level domain (TLD): at least two letters (e.g. com, uk, museum).
$ End of the string. Prevents extra characters after the email.
i Case-insensitive flag. TEST@EXAMPLE.COM matches just like test@example.com.
Assumption
This regex aims for practical email validation, not full RFC 5322 compliance. That's the most common interpretation for web forms in JavaScript.
3. TEST RESULTS
Must match
Input Result
test@site.com ✅ Pass
a.b@example.co.uk ✅ Pass
Must NOT match
Input Result
plain text ✅ No match
@nope.com ✅ No match (missing local part)
user@ ✅ No match (missing domain)
a@b ✅ No match (no .TLD)
All required examples behave as requested.
4. EDGE CASES
This regex intentionally keeps things readable, so there are some trade-offs.
It accepts
user+tag@example.com ✅
USER@EXAMPLE.COM ✅ (because of i)
first_last@example.org ✅
user-name@example-domain.com ✅
It also accepts (although technically invalid)
user..name@example.com
.user@example.com
user.@example.com
user@example..com
user@-example.com
These are invalid according to the email specification, but preventing them makes the regex considerably more complex.
It rejects
a@b ❌ (no valid TLD)
user@localhost ❌
user@[192.168.1.1] ❌
Internationalized email addresses like 用户@example.com ❌
If you need any of these, you'll need a different pattern or dedicated email validation.
5. VARIATIONS
Stricter version
Prevents leading/trailing dots in the local part, consecutive dots there, and requires each domain label to start and end with an alphanumeric character.
regex
/^(?!.*\.\.)[A-Z0-9_%+-]+(?:\.[A-Z0-9_%+-]+)*@(?:[A-Z0-9](?:[A-Z0-9-]*[A-Z0-9])?\.)+[A-Z]{2,}$/i
Compared to the basic version, this rejects examples like:
.user@example.com
user.@example.com
user..name@example.com
user@example..com
user@-example.com
Looser version
Allows almost anything except whitespace and requires only an @ and a dot after it.
regex
/^\S+@\S+\.\S+$/i
This is useful when you want minimal validation and plan to verify addresses another way (for example, by sending a confirmation email). It may accept some malformed addresses that the stricter patterns reject.
JavaScript notes
The pattern is written as a JavaScript regex literal: /.../i.
The i flag provides case-insensitive matching.
The ^ and $ anchors ensure the entire string must be a valid email address, satisfying the "match the whole string" requirement.
By purchasing this prompt, you agree to our terms of service
GPT-5.6
Describe what you want to match in plain English and get a working regex — no more trial and error. Give the goal, examples that must and must not match, the flavor (JavaScript, Python, PCRE...), and rules like case sensitivity; get back the pattern, a plain-English breakdown of each part, test results on your examples, edge cases, and looser or stricter variants. Great for developers, data cleanup, and no-coders. From idea to tested pattern in seconds.
...more
Added 2 weeks ago
