Email Address Validation
Robust email validation using RFC 5322 compliant regular expression
Implementation
Copy the complete example or adapt its typed interface to your project. Comments are kept inside the snippet so the intent travels with the code.
/**
* Validate email address format
* @param email Email address to validate
* @returns True if valid email, false otherwise
*/
function isValidEmail(email: string): boolean {
const re = /^[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])?)*$/;
return re.test(email);
}
// Usage Example
console.log(isValidEmail('[email protected]')); // true
console.log(isValidEmail('[email protected]')); // true
console.log(isValidEmail('invalid-email')); // falseWhen to use it
Essential for form validation, user registration, or any scenario requiring email format verification
Review the input assumptions and browser or runtime support before adopting a utility unchanged. Small helpers are easiest to maintain when their contract stays narrow.
Reasoning and trade-offs
How it works
The regular expression checks a practical address shape: non-space content on both sides of an at sign and a dotted domain segment. It catches common typing mistakes without attempting to implement the full email specification.
What to watch for
Valid international or unusual addresses may be rejected, while syntactically plausible addresses may not exist. Regex validation cannot prove deliverability, mailbox ownership, or whether a domain accepts mail.
Production use
Use this check for immediate form feedback, then validate length and normalize according to product rules. Verification email is the reliable ownership test; the server must remain authoritative even when the browser reports success.
Before you ship
- Confirm the input contract with tests that cover empty, invalid, boundary, and representative real-world values before sharing the helper across a codebase.
- Keep the function focused on one responsibility and name any project-specific policy explicitly instead of hiding it inside a generic-looking utility.
- Measure behavior in the browsers or runtime versions your product supports, especially when timing, storage, DOM state, locale, or network access is involved.
- Document the return type, mutation behavior, failure mode, and performance characteristics beside the call site so future maintainers can evaluate changes safely.
- Compare the example with current official platform documentation when it relies on a browser API, language feature, or runtime behavior that may change over time.
- If the helper crosses a trust boundary, validate again on the server and avoid treating browser-side checks, TypeScript annotations, or formatted output as a security guarantee.
- Add a small regression test whenever a real edge case is discovered; concrete examples preserve the reason behind a guard more reliably than a general comment.