Client side email verification runs in your browser. It parses your CSV, flags bad syntax, duplicates, and disposable domains locally, so raw lists never leave your device. Server side verification then confirms real mailboxes with MX record lookups and SMTP checks. You need both: privacy first, then deliverability proof.
What is client side email verification?
Client side email verification is validation that happens in your browser before anything is sent to a server. It checks each address for syntax errors, removes duplicates, flags known disposable domains, and suggests typo fixes. No quota is spent and no data is uploaded. It runs the moment you paste or drop a file.
This layer is fast because it never makes a network call for the obvious problems. Syntax rules catch a missing @, a stray space, or a malformed domain. A local list flags throwaway addresses from providers like mailinator.com or 10minutemail. Duplicate detection trims the same address entered twice, which is common when you merge exports from two tools. Typo suggestions fix the classics, gmial.com to gmail.com, so you recover real contacts instead of deleting them. None of this spends quota.
What does server side verification confirm?
Server side verification confirms whether a mailbox actually exists. Your device asks the recipient domain for its MX records, then opens an SMTP conversation to test the specific address. The mail server responds, and that response decides the verdict. Browser rules cannot do this because mail servers only talk to other servers.
Our verification engine handles this hop for you. It reads the MX records, connects at the SMTP level, and turns the reply into a clear verdict: Deliverable, Risky, Invalid, or Unknown. Risky covers catch-all domains, role accounts like info@ or sales@, and disposable providers that slipped past the local scan. Invalid means the mailbox does not exist. Unknown means the server would not give a straight answer, which happens with greylisting and strict firewalls. This is the proof a browser check cannot supply.
Why browser side CSV parsing protects your list
Your contact list is an asset. Uploading a raw CSV to an unknown server means trusting a stranger with names, addresses, and sometimes revenue signals. Browser side parsing removes that risk. When you drop a file into the free tool, JavaScript reads it on your own machine. The file itself never leaves your device.
Only the addresses that need a live mailbox check trigger a network request, and each one goes out as an individual lookup, not as your whole spreadsheet. Syntax errors, duplicates, and disposable domains are already gone by then. So the data that touches any server is minimal, and the full list stays with you.
For teams handling customer data under GDPR or similar rules, that boundary matters. A list that never leaves the browser is a list you never have to explain in a vendor security review. It is one less dataset sitting on a third party server, waiting to be part of someone else's breach. Privacy and speed come from the same design choice.
Client side vs server side, side by side
The two layers do not compete. They cover different failure modes. This is how the work splits.
| Check | Runs where | Uses quota | Catches |
|---|---|---|---|
| Syntax validation | Browser | No | Typos, malformed addresses |
| Duplicate removal | Browser | No | Repeat entries |
| Disposable domain flag | Browser | No | Throwaway inboxes |
| MX record lookup | Server | Yes | Domains with no mail server |
| SMTP mailbox check | Server | Yes | Dead or full mailboxes |
| Catch-all detection | Server | Yes | Domains that accept everything |
Read it top to bottom and the pattern is clear. The free browser checks remove volume for nothing. The server checks cost one verification each but deliver the answer that actually protects your domain. Skip the browser layer and you upload data you did not need to share. Skip the server layer and you send to addresses that look fine but bounce.
Does client side verification catch everything?
No. Client side verification is a filter, not a final verdict. It removes obvious waste: bad syntax, duplicates, and known disposable domains. It cannot tell you if a well formed address points to a live mailbox, because that answer only exists on the mail server. Treat it as the fast first pass, not the whole job.
The reverse is also true. Server side checks are accurate but slower and rate limited, so running them on a list full of duplicates wastes time and quota. That order is not a nice to have. It is the difference between a verification budget that lasts and one you exhaust on garbage. Clean locally, then verify what remains. The free tool runs both steps in that sequence automatically, so you get the speed of a local scan and the certainty of a live mailbox check without choosing between them.
Try it on your next list. Paste up to 10 addresses a day with no signup, or enter just an email to lift the limit to 100 a day, no password and no card. Your CSV is parsed in the browser and never uploaded, and every remaining address gets a real MX and SMTP check. If you would rather hand off list building and outreach entirely, Synthisia runs that pipeline for you, but the verifier is free to use on its own.
Check your list right now, free
10 checks a day with no signup. 100 a day with just your email.
How to run both layers in one pass
You do not need two tools. A good verifier layers the checks so the cheap ones run first. This is the order that saves the most quota.
- Paste your addresses or drop a CSV. The file is parsed locally, so nothing uploads.
- Let the safety scan strip bad syntax, duplicates, and disposable domains without using quota.
- Review the typo suggestions and accept the obvious fixes, like gmial.com to gmail.com.
- Send the remaining addresses through MX and SMTP level mailbox checks.
- Read the verdicts, then export the clean list as CSV or JSON.
Run in that sequence and you spend live checks only on addresses that survived the free filter. On a typical scraped list, that removes a large share of the file before a single mailbox lookup.
The bottom line
Client side and server side verification are not rivals. One protects your data and your time, the other protects your sender reputation. Use the browser layer to clean fast and keep your list private. Use the server layer to confirm real mailboxes before you hit send. Keep hard bounces under 2 percent and inbox placement follows. Set the two layers up once and every future import gets the same treatment. The free tool gives you both in one pass, so there is little reason to skip either.