Regex Builder

Continue in the tool

More pages for this tool

email regex

Email regex

The formal email specification, RFC 5322, is too long to turn into a regex for everyday use. This preset uses a pragmatic pattern and shows, with real cases, where that simplification gets it right and where it cuts the address in half.

Why "validating email" is harder than it looks

RFC 5322, the document that defines the official email address syntax, allows structures that are rare in practice: a quoted local part, comments in parentheses and escaped special characters. A regex that covered all of that to the letter becomes unreadable and expensive to maintain, so nearly every real system uses a pragmatic pattern instead, like this preset `\b\w+@\w+\.\w{2,}\b`, which accepts the common `[email protected]` shape.
The price of that simplicity is that `\w` only covers letters, digits and underscore, with no dot or plus sign. That means a perfectly valid address like `[email protected]` does not match in full: the search only finds `[email protected]`, because the dot and the plus sign break the run of `\w` characters and leave the start of the address out of the result.
Even a more thorough regex only proves the text has the shape of an email, never that the inbox exists and actually receives messages. The only real confirmation is the classic opt-in flow: send an email with a link or code and wait for confirmation to come back from that address.

Three real pattern behaviors

Simple address

Input: [email protected]
Expected output: match completo: [email protected]

Both local part and domain use only letters, and the `.tools` TLD has 5 letters, so all three `\w+@\w+\.\w{2,}` blocks match the whole string.

Address with dot and plus

Input: [email protected]
Expected output: match parcial: [email protected]

The address is valid, but the pattern only sees the part after the plus sign; `user.name+` is left out because `\w` does not include a dot or a `+`.

Text without an at-sign

Input: not-an-email
Expected output: sem match

With no literal `@` in the middle of the string, the pattern has nowhere to anchor the split between local part and domain, so no part of the text matches.

Full tool FAQ

Does the tool test regex patterns with flags and examples?

Yes. The idea is to let you build the expression, apply flags and inspect matches in real time, which is especially useful for debugging, learning and fine-tuning patterns.

What is regex?

What is regex used for in practice?

What are regex flags?

Can regex validate any complex format?

Why do some regex patterns become too slow?

Is there such a thing as a perfect email regex?

What is the most common mistake when learning regex?

Frequently asked questions

Does this regex validate every address the specification allows?

No. RFC 5322 allows quoted local parts, comments and escaped characters that this pragmatic pattern does not try to cover. It focuses on the common `[email protected]` shape, which is what shows up in nearly every real form.

Does the regex confirm the email really exists?

No, it only confirms text shape. Proving that the inbox exists and receives messages requires sending a confirmation email with a link or code and waiting for the click or reply to come back from that address.

Why does "[email protected]" not match in full?

Because the pattern `\w` class does not include a dot or a plus sign, two characters common in real addresses that use an alias (the `+tag`) or a compound name. The match only starts after the last character outside `\w`, cutting off the beginning of the address.

Next steps

Continue in the tool

Open full tool

email regex

Email regex

Why "validating email" is harder than it looks

RFC 5322, the document that defines the official email address syntax, allows structures that are rare in practice: a quoted local part, comments in parentheses and escaped special characters. A regex that covered all of that to the letter becomes unreadable and expensive to maintain, so nearly every real system uses a pragmatic pattern instead, like this preset `\b\w+@\w+\.\w{2,}\b`, which accepts the common `[email protected]` shape.

The price of that simplicity is that `\w` only covers letters, digits and underscore, with no dot or plus sign. That means a perfectly valid address like `[email protected]` does not match in full: the search only finds `[email protected]`, because the dot and the plus sign break the run of `\w` characters and leave the start of the address out of the result.

Even a more thorough regex only proves the text has the shape of an email, never that the inbox exists and actually receives messages. The only real confirmation is the classic opt-in flow: send an email with a link or code and wait for confirmation to come back from that address.

Three real pattern behaviors

Simple address

Input: [email protected]
Expected output: match completo: [email protected]

Both local part and domain use only letters, and the `.tools` TLD has 5 letters, so all three `\w+@\w+\.\w{2,}` blocks match the whole string.

Address with dot and plus

Input: [email protected]
Expected output: match parcial: [email protected]

The address is valid, but the pattern only sees the part after the plus sign; `user.name+` is left out because `\w` does not include a dot or a `+`.

Text without an at-sign

Input: not-an-email
Expected output: sem match

With no literal `@` in the middle of the string, the pattern has nowhere to anchor the split between local part and domain, so no part of the text matches.

Full tool FAQ

Does the tool test regex patterns with flags and examples?

Yes. The idea is to let you build the expression, apply flags and inspect matches in real time, which is especially useful for debugging, learning and fine-tuning patterns.

What is regex?

What is regex used for in practice?

What are regex flags?

Can regex validate any complex format?

Why do some regex patterns become too slow?

Is there such a thing as a perfect email regex?

What is the most common mistake when learning regex?

Frequently asked questions