Regex for an email-ish address (and what it cannot tell you)

/^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/

/^[a-zA-Z0-9!#$%&'*+\/=?^_`{|}~-]+(?:\.[a-zA-Z0-9!#$%&'*+\/=?^_`{|}~-]+)*@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/

How it works

The WHATWG HTML Standard defines a valid email address with an ABNF: 1*( atext / "." ) "@" label *( "." label ), where atext is the RFC 5322 set of printable characters and the label comes from RFC 1034 (letters, digits, hyphens, at most 63 characters, starting and ending with a letter or digit). It then says this requirement is "a willful violation of RFC 5322", which it calls too strict before the at sign, too vague after it, and too lax in allowing comments, whitespace and quoted strings. The first pattern is the JavaScript- and Perl-compatible expression the standard prints for that definition.

The second pattern tightens one thing only: the local part must follow RFC 5322's dot-atom-text, which does not allow a leading, trailing or doubled dot. That is a change this page makes to the standard's pattern; the standard itself says a dot may appear anywhere. It does not change the domain part.

What neither pattern decides: whether the domain exists, whether it accepts mail, whether the mailbox exists, or whether the person typing it owns it. Only sending a message and having the owner act on it (for example, click a link) proves that. This is why so many sites send a confirmation email and treat the pattern as a typo filter.

Known false positives

• a@b and user@localhost pass: neither has a dot in the domain, which the standard allows. Add (?:\.label)+ instead of * if you need at least one dot.
• The WHATWG pattern accepts a leading, trailing or doubled dot in the local part; the stricter variant rejects those.
• Both patterns accept addresses that look right but cannot receive mail: no-one@example.com, or a well-formed address on a domain that does not exist.

Known false negatives

• Addresses with quoted local parts ("john doe"@example.com), domain literals (user@[192.168.0.1]) and comments are valid under RFC 5322 but rejected by both patterns.
• Internationalized addresses with non-ASCII characters in the local part are rejected. RFC 6531 extends atext with non-ASCII characters (UTF8-non-ascii) for mail systems that support it. Non-ASCII domain names must be converted to their ASCII (punycode) form before the pattern sees them; browsers do this in input type=email, and the standard describes that conversion.
• A trailing dot (user@example.com.) is rejected.

Flavor notes

• The patterns use a character class with many punctuation characters. Inside a class, only ], \, ^ (first) and - (between characters) are special in the flavors on this site, which is why the hyphen is placed last. The backslash before the slash is only needed in a JavaScript regex literal; it is harmless in a string.
• Neither pattern uses lookaround, so both compile in JavaScript, PCRE2 and Go (RE2 syntax) and are run on those real engines by the tests. Python and Java are notes only on this site.
• Trailing newline: PCRE2 (default), Python and Java let $ match before a final newline, so "user@example.com" followed by a line feed would pass; JavaScript and Go reject it. Use \z, \Z, fullmatch() or matches() in those flavors.

Why not regex here?

For a form on a web page, let the browser do the first check: <input type="email"> applies the same WHATWG definition and handles internationalized domain names for you. Then send a confirmation email. The regex is useful where no browser is involved, for example when a server must reject obvious junk before queueing mail.

Do not write a regex that tries to implement all of RFC 5322. The standard's authors judged the full grammar unfit for validation and chose a simpler definition on purpose.