- \n
- Use client-side validation to catch typos early and reduce failed form submissions.<\/li>\n\n\n\n
- Regex, HTML5 validation, and validator.js confirm format, not deliverability.<\/li>\n\n\n\n
- For higher-quality signups, add a server-side or API check to block disposable and invalid emails.<\/li>\n\n\n\n
- Validate at the right time: on blur or on submit, not on every keystroke.<\/li>\n\n\n\n
- Treat validation as a layered system: user experience first, enforcement on the backend.<\/li>\n<\/ul>\n\n\n\n
Why validate emails in JavaScript?<\/h2>\n\n\n\n
JavaScript email validation acts as a first filter<\/strong> before data reaches your backend. It runs in the browser, allowing forms to catch obvious mistakes immediately instead of waiting for a server response.<\/p>\n\n\n\n
Client-side validation helps in several ways.<\/p>\n\n\n\n
Catch errors early<\/h3>\n\n\n\n
Users receive instant feedback<\/strong> when an email is incorrectly formatted instead of discovering the problem after submitting the form. Validating on blur or submit helps users fix issues quickly and keeps form flows smooth.<\/p>\n\n\n\n
Filter invalid input before submission<\/h3>\n\n\n\n
Basic checks prevent malformed addresses<\/strong> such as john.doe@ or @example.com from reaching your server. This cuts out unnecessary requests and keeps clearly invalid data out of your system.<\/p>\n\n\n\n
Improve validation without replacing backend checks<\/h3>\n\n\n\n
JavaScript can confirm that an email looks valid, but it can\u2019t verify whether the mailbox exists or accepts mail. Server-side or API validation is still required for enforcement.<\/p>\n\n\n\n
Works alongside HTML5 validation<\/h3>\n\n\n\n
Modern browsers already provide basic format checking with type=”email”. JavaScript can extend this by adding custom rules or error messages<\/strong>.<\/p>\n\n\n\n
<input type=”email” id=”userEmail” required><\/p>\n\n\n\nconst emailInput = document.getElementById(‘userEmail’);
<\/p>\n\n\n\nemailInput.addEventListener(‘input’, () => {<\/p>\n\n\n\n
if (!isValidEmail(emailInput.value)) {<\/p>\n\n\n\n
emailInput.setCustomValidity(‘Please enter a valid email address.’);<\/p>\n\n\n\n
} else {<\/p>\n\n\n\n
emailInput.setCustomValidity(”);<\/p>\n\n\n\n
}<\/p>\n\n\n\n
});<\/p>\n\n\n\n
Client-side validation improves form usability, but it is only the first layer.<\/p>\n\n\n\n
Validating emails with regular expressions (regex)<\/h2>\n\n\n\n
Regular expressions (regex) are the most common way to validate email format in JavaScript. They\u2019re fast, flexible, and easy to run client-side, but the pattern needs to strike a balance between strict and practical validation.<\/p>\n\n\n\n
What Are Regular Expressions? – RegEx Beginner Tutorial<\/a><\/p>\n\n\n\n
What regex can (and can\u2019t) do<\/h3>\n\n\n\n
Email formats are defined by RFC 5322<\/a>, but fully matching the specification with regex isn\u2019t realistic. Most implementations aim to catch obvious formatting mistakes rather than every theoretical edge case.<\/p>\n\n\n\n
A widely used basic pattern<\/strong> looks like this:<\/p>\n\n\n\n
const emailRegex = \/^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$\/;<\/p>\n\n\n\n
This checks for:<\/p>\n\n\n\n
- \n
- characters before the @<\/li>\n\n\n\n
- characters between @ and the final .<\/li>\n\n\n\n
- a domain suffix such as .com or .org<\/li>\n<\/ul>\n\n\n\n
It works well for general validation but still allows some invalid inputs<\/strong>, such as user@.com<\/em>, and may accept development-only addresses like user@localhost<\/em>.<\/p>\n\n\n\n
Using a stricter pattern<\/h3>\n\n\n\n
If you need tighter format checks, a stricter regex can help:<\/p>\n\n\n\n
const strictEmailRegex =<\/p>\n\n\n\n
\/^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$\/;<\/p>\n\n\n\n
This version:<\/p>\n\n\n\n
- \n
- restricts allowed characters in the local part<\/li>\n\n\n\n
- requires a valid-looking domain<\/li>\n\n\n\n
- blocks common malformed addresses<\/li>\n<\/ul>\n\n\n\n
Even so, regex should focus on catching common mistakes, not enforcing the full email specification.<\/p>\n\n\n\n
Don\u2019t over-engineer regex<\/h3>\n\n\n\n
Attempting full RFC compliance usually creates patterns that are:<\/p>\n\n\n\n
- \n
- difficult to read<\/li>\n\n\n\n
- hard to maintain<\/li>\n\n\n\n
- still imperfect in practice
<\/li>\n<\/ul>\n\n\n\nA clear, maintainable pattern tested against real inputs is almost always the better choice. For deeper validation<\/strong>, use a library or verification service instead.<\/p>\n\n\n\n
Test with real examples<\/h3>\n\n\n\n
Always test regex against realistic data.<\/p>\n\n\n\n
Valid examples<\/strong><\/p>\n\n\n\n
- \n
- john.doe@example.com<\/em><\/li>\n\n\n\n
- user+alias@sub.domain.co.uk<\/em><\/li>\n\n\n\n
- first_last123@domain.io<\/em>
<\/em><\/li>\n<\/ul>\n\n\n\nInvalid examples<\/strong><\/p>\n\n\n\n
- \n
- plainaddress<\/em><\/li>\n\n\n\n
- @missingusername.com<\/em><\/li>\n\n\n\n
- user@.invalid.com<\/em><\/li>\n<\/ul>\n\n\n\n
Tools like regex101.com<\/a> make it easy to verify behavior before deploying.<\/p>\n\n\n\n
When regex is the right choice<\/h3>\n\n\n\n
Regex works best for quick client-side format checks and immediate user feedback. It should be treated as the first validation layer, not proof that an email address actually exists.<\/p>\n\n\n\n
Using HTML5 built-in validation API<\/h2>\n\n\n\n
Modern browsers already include basic email validation through HTML5 form inputs. Using type=”email”<\/em> applies built-in format checks automatically, with no JavaScript required.<\/p>\n\n\n\n
How HTML5 email validation works<\/h3>\n\n\n\n
When an input uses the email<\/em> type, the browser verifies that the value follows a general email structure (something@domain.tld<\/em>) before allowing submission.<\/p>\n\n\n\n
<form id=”signup-form”><\/p>\n\n\n\n
<label for=”email”>Email:<\/label><\/p>\n\n\n\n
<input type=”email” id=”email” name=”email” required><\/p>\n\n\n\n
<button type=”submit”>Submit<\/button><\/p>\n\n\n\n
<\/form><\/p>\n\n\n\n
The browser will:<\/p>\n\n\n\n
- \n
- block submission if the field is empty or incorrectly formatted<\/li>\n\n\n\n
- highlight invalid fields automatically<\/li>\n\n\n\n
- display a default validation message<\/li>\n<\/ul>\n\n\n\n
For many forms, this provides enough baseline validation without extra code.<\/p>\n\n\n\n
Access validation state with JavaScript<\/h3>\n\n\n\n
You can extend native validation using the HTML5 validation API.<\/p>\n\n\n\n
Use checkValidity()<\/em> to test inputs programmatically:<\/p>\n\n\n\n
const form = document.getElementById(‘signup-form’);<\/p>\n\n\n\n
form.addEventListener(‘submit’, (e) => {<\/p>\n\n\n\n
if (!form.checkValidity()) {<\/p>\n\n\n\n
e.preventDefault();<\/p>\n\n\n\n
}<\/p>\n\n\n\n
});<\/p>\n\n\n\n
Each input also exposes validation data:<\/strong><\/p>\n\n\n\n
const emailInput = document.getElementById(’email’);<\/p>\n\n\n\n
if (!emailInput.validity.valid) {<\/p>\n\n\n\n
console.log(emailInput.validationMessage);<\/p>\n\n\n\n
}<\/p>\n\n\n\n
This allows custom handling without writing regex logic yourself.<\/p>\n\n\n\n
Customizing validation behaviour<\/h3>\n\n\n\n
HTML attributes control most validation rules:<\/p>\n\n\n\n
- \n
- required: field must be filled<\/li>\n\n\n\n
- pattern: apply custom regex rules<\/li>\n\n\n\n
- minlength \/ maxlength: limit input length<\/li>\n<\/ul>\n\n\n\n
Example restricting emails to one domain:<\/strong><\/p>\n\n\n\n
<input<\/p>\n\n\n\n
type=”email”<\/p>\n\n\n\n
pattern=”^[a-zA-Z0-9._%+-]+@example\\.com$”<\/p>\n\n\n\n
required><\/p>\n\n\n\n
To override browser error messages:<\/strong><\/p>\n\n\n\n
emailInput.addEventListener(‘input’, () => {<\/p>\n\n\n\n
if (!emailInput.validity.valid) {<\/p>\n\n\n\n
emailInput.setCustomValidity(<\/p>\n\n\n\n
‘Please enter a valid @example.com email address’<\/p>\n\n\n\n
);<\/p>\n\n\n\n
} else {<\/p>\n\n\n\n
emailInput.setCustomValidity(”);<\/p>\n\n\n\n
}<\/p>\n\n\n\n
});<\/p>\n\n\n\n
When HTML5 validation is enough<\/h3>\n\n\n\n
Built-in validation works well for:<\/p>\n\n\n\n
- \n
- basic format checks<\/li>\n\n\n\n
- required fields<\/li>\n\n\n\n
- simple domain restrictions
<\/li>\n<\/ul>\n\n\n\nIt keeps forms lightweight and dependency-free. However, it only validates structure. It cannot confirm whether an address exists or accepts mail.<\/p>\n\n\n\n
Using third-party libraries (validator.js)<\/h2>\n\n\n\n
If you don\u2019t want to maintain regex patterns, libraries like validator.js<\/strong> provide a cleaner approach to format validation.<\/p>\n\n\n\n
Why use Validator.js<\/h3>\n\n\n\n
Validator.js exposes a single method for email validation:<\/p>\n\n\n\n
const validator = require(‘validator’);<\/p>\n\n\n\n
validator.isEmail(‘user@example.com’); \/\/ true<\/p>\n\n\n\n
validator.isEmail(‘not-an-email’); \/\/ false<\/p>\n\n\n\n
The library handles edge cases and evolving standards, avoiding fragile custom regex.<\/p>\n\n\n\n
Customizing validation rules<\/h3>\n\n\n\n
isEmail() <\/em><\/strong>accepts configuration options:<\/strong><\/p>\n\n\n\n
validator.isEmail(‘John Doe <john@example.com>’, {<\/p>\n\n\n\n
allow_display_name: true<\/p>\n\n\n\n
});<\/p>\n\n\n\n
Common options include:<\/p>\n\n\n\n
- \n
- allow_display_name<\/li>\n\n\n\n
- require_tld<\/li>\n\n\n\n
- allow_ip_domain<\/li>\n\n\n\n
- domain_specific_validation<\/li>\n<\/ul>\n\n\n\n
This allows stricter or more flexible validation without rewriting logic.<\/p>\n\n\n\n
Using validator.js in forms<\/h3>\n\n\n\n
Validator.js works in vanilla JS or frameworks like React:<\/p>\n\n\n\n
function handleSubmit(event) {<\/p>\n\n\n\n
event.preventDefault();<\/p>\n\n\n\n
const email = event.target.email.value;<\/p>\n\n\n\n
if (!validator.isEmail(email)) {<\/p>\n\n\n\n
setError(‘Invalid email address’);<\/p>\n\n\n\n
return;<\/p>\n\n\n\n
}<\/p>\n\n\n\n
}<\/p>\n\n\n\n
Lightweight and practical<\/h3>\n\n\n\n
Validator.js adds roughly 20KB minified and has no external dependencies. Bundlers can tree-shake unused functions, keeping builds small.<\/p>\n\n\n\n
It simplifies client-side format validation, but like HTML5 and regex, it only checks structure<\/strong>. Confirming whether an email is real requires verification beyond the browser.<\/p>\n\n\n\n
![\"\"](\"https:\/\/emaillistverify.com\/blog\/wp-content\/uploads\/2026\/03\/image-1.png\")
<\/figure>\n\n\n\nLayered email validation flow<\/em><\/p>\n\n\n\n
Why client-side validation isn’t enough<\/h2>\n\n\n\n
Client-side validation is useful for catching formatting mistakes before a form is submitted. It helps users fix obvious errors early, but it cannot confirm whether an email address is real or deliverable. Even addresses that pass browser-based checks can still be invalid or unusable.<\/p>\n\n\n\n
Here\u2019s what client-side validation cannot detect.<\/p>\n\n\n\n
Syntax checks don\u2019t guarantee real addresses<\/h3>\n\n\n\n
Most client-side validation relies on regex or browser rules to confirm that an email looks correct. These checks catch missing @ symbols or invalid characters, but they cannot verify that a mailbox actually exists<\/strong>.<\/p>\n\n\n\n
For example, john.doe@gnail.con<\/em> passes many format checks even though the domain is clearly a typo. Without deeper validation, addresses like this enter your system and fail later when emails are sent.<\/p>\n\n\n\n
Disposable and role-based emails still pass<\/h3>\n\n\n\n
Client-side scripts cannot identify temporary or generic addresses such as test@tempmail.net<\/em> or support@domain.com<\/em>. These may pass format validation but often do not represent real users.<\/p>\n\n\n\n
This can lead to:<\/p>\n\n\n\n
- \n
- inaccurate analytics<\/li>\n\n\n\n
- failed onboarding flows<\/li>\n\n\n\n
- low-quality signups
<\/li>\n<\/ul>\n\n\n\nDetecting these patterns requires server-side logic or an external verification service.<\/p>\n\n\n\n
No domain or mailbox verification<\/h3>\n\n\n\n
Browsers cannot check DNS records or confirm whether a mail server accepts messages. An address like user@nonexistentdomain123.com<\/em> may match a regex pattern even though the domain doesn\u2019t exist.<\/p>\n\n\n\n
Domain and mailbox checks require server-side processing or an API <\/strong>capable of querying mail infrastructure.<\/p>\n\n\n\n
Client-side checks can be bypassed<\/h3>\n\n\n\n
Because validation runs in the browser, users can disable or modify it using developer tools. Client-side validation improves usability, but it cannot enforce data quality on its own.<\/p>\n\n\n\n
Server-side validation remains the final authority.<\/strong><\/p>\n\n\n\n
Client-side validation improves the form experience, but it is only the first layer. To catch fake, disposable, or undeliverable emails, validation needs to continue after submission.<\/p>\n\n\n\n
How to use EmailListVerify’s API for real-time checks<\/h2>\n\n\n\n
Once client-side validation is in place, you can verify emails in real time using the EmailListVerify API<\/a>. This adds a second validation layer<\/strong> that checks whether an address is actually usable before storing it or triggering workflows.<\/p>\n\n\n\n
Get your API key<\/h3>\n\n\n\n
Copy your API key from the API section in your EmailListVerify dashboard. This key authenticates all requests, so keep it private<\/strong>.<\/p>\n\n\n\n
![\"\"](\"https:\/\/emaillistverify.com\/blog\/wp-content\/uploads\/2026\/03\/image-1024x380.png\")
<\/figure>\n\n\n\nDon\u2019t have an EmailListVerify account yet? You can create one for free<\/strong>.<\/p>\n\n\n\n
[Get free API key]<\/p>\n\n\n\n
Verify an email address<\/h3>\n\n\n\n
Real-time validation uses the verifyEmail <\/em>endpoint:<\/p>\n\n\n\n
- @missingusername.com<\/em><\/li>\n\n\n\n
- user+alias@sub.domain.co.uk<\/em><\/li>\n\n\n\n
- john.doe@example.com<\/em><\/li>\n\n\n\n