Email List Cleaner

The email marketing industry runs on one quiet fear: the bounce. You import a list, hit send, and twenty minutes later the dashboard is red — unknown addresses, syntax rejections, a duplicate or three hundred. Enough hard bounces in one campaign and your email service provider throttles you, or quarantines the campaign, or in the worst case pauses the account pending a list-quality review. Every paid cleaning service sells relief from exactly that moment.

But look at what the list actually contains, and the expensive version of the problem shrinks. Most of it is mechanical: duplicates with different casing, addresses missing their top-level domain, double @ signs from a bad copy-paste, typos in the big three providers. Syntax problems. Duplicate problems. All fixable with pure computation — no mail-server probing, no API credits, no per-thousand pricing. What genuinely requires SMTP verification (does this mailbox exist right now?) is a different, smaller job, and this tool does not pretend to do it.

So: paste the list, get a clean list. Duplicates removed with the case rules real mail systems use, syntax failures pulled into their own file so you can fix or discard them deliberately, common typo domains suggested for one-click review, role addresses flagged. Invalid rows are never silently dropped — the export separates them, because a discarded address might be a customer whose email you merely mistyped.

And the whole operation runs in your browser. A full customer email list is not something to paste into a web service that promises privacy in its footer — it is the exact file that should never cross the network for a computation your own machine does instantly. More on the honest limits of syntax checking below; first, the workflow.

The cleaner is above this section. The standard run on an exported list:

1. 1

   Paste the list or load the CSV

   A bare list (one address per line) or a full CSV with an email column among others — both work. For CSVs, pick the email column and every other column travels with the rows, so your clean export keeps names, signup dates and tags intact.

2. 2

   Set the dedupe rules

   Case-insensitive matching is on by default, and Gmail dot-normalization is a toggle. Strict mode (byte-exact matching) is available when your use case genuinely distinguishes casings, which is almost never.

3. 3

   Run the clean

   One pass computes everything: duplicates, syntax failures, typo suggestions against the common-provider domain list, and role-address flags. Progress is instant on lists into the hundreds of thousands.

4. 4

   Review the report

   Rows in, unique clean addresses out, duplicates removed (with the spellings that collapsed), invalid addresses with per-row reasons, typo suggestions awaiting your click, role flags. Every number is a row count you can verify by eye on a sample.

5. 5

   Export three files

   The clean list, the invalid rows with reasons, and the removed duplicates — as CSV or plain list. The separation is deliberate: the clean file is what you send to; the other two are what you fix or archive.

The three-file export deserves a moment of appreciation before you delete anything. The invalid file is often the most valuable of the three: it is a worklist of possibly-real customers with recoverable mistakes, and treating it as garbage is how companies lose contacts they paid to acquire.

The tool's checks, stated precisely. Syntax first: an email address is local-part@domain, and the cleaner applies the practical subset of the RFC 5322 grammar that separates broken from plausible: exactly one @, a non-empty local part (the RFC permits up to 64 characters), a domain of dot-separated labels that are non-empty and reasonably long, and no spaces or characters forbidden in unquoted forms. A full RFC 5322 parser would accept constructions like "very.unusual"@example.com that no mailbox accepts; a naive one rejects accented internationalized addresses that real systems deliver. The practical middle — plus explicit support for internationalized domains — is where correctness lives for list cleaning.

Duplicates second, under the rules that mail systems actually enforce. Domain parts are case-insensitive by definition. Local parts are technically case-sensitive per the SMTP specification but universally treated case-insensitively by every major provider — so alice@Company.com and ALICE@company.com are one recipient with three spellings. The cleaner collapses them, keeping first-seen casing. Gmail adds its famous quirks: dots in the local part are ignored (jane.doe@gmail.com is jane@gmail.com), and googlemail.com is an alias for gmail.com. Dot-collapsing is Gmail-only because other providers — including Outlook and most corporate servers — treat dots as significant characters, and merging distinct addresses there is a data-loss bug wearing a cleanup costume.

Typos third, by edit distance against the common providers. The Damerau-Levenshtein distance counts insertions, deletions, substitutions and transpositions — gmial.com is one transposition away from gmail.com, hotmial.com one insertion away from hotmail.com. Distance of one or two against the provider list produces a suggestion; the suggestion sits in a review column until you accept it, because silently rewriting a customer's address to a plausible guess is how mail lands in a stranger's inbox. The typo list also catches the classic finger-slips: conm.com for com, and the gmail/googlemail duality that splits one provider into two apparent domains.

Role addresses last: info@, sales@, support@, admin@, billing@, careers@, no-reply@ and friends are function inboxes, not people. The cleaner flags rather than removes them — a transactional receipt to billing@ is legitimate; a marketing blast to it is a deliverability risk most ESP scoring already penalizes. Your call, not the tool's.

A small export with every problem the cleaner exists for. Count along — the arithmetic is the credibility.

Read the output files the way a careful operator would. The clean list is six rows, one of which (carol) still carries its typo pending review — the suggestion is attached, not applied, and clicking it swaps the domain to gmail.com. The invalid file is a three-row worklist: dave might be dave@company.com with the .com clipped by a form; grace is probably a website domain pasted by mistake; eve's double @ is a merge artifact. The duplicate file shows that alice signed up — or was exported — three times, which is worth knowing independent of cleaning: triple-recorded customers usually mean a form bug, not an enthusiastic user.

Scaled to real lists, the shape holds: a 20,000-row legacy list typically sheds a few hundred exact-and-case duplicates, a hundred or so syntax casualties, and a handful of recoverable typo domains — and the send afterwards runs cleaner because the mailbox infrastructure stopped seeing the same recipient three times under three spellings.

The same human being can appear in your list under several spellings, and dedupe quality is exactly the quality of your rules for seeing through disguises. The full catalog, from obvious to subtle:

The plus-tag row rewards a pause. jane+news@gmail.com and jane+promos@gmail.com reach the same mailbox, but the tags exist so the recipient — and you — can track which signups produce which mail. Collapsing them is right before a bulk send (one message per human) and wrong for analytics (the tags are data). Making it a toggle is the only defensible design; burying it as an always-on behavior would quietly destroy signal.

The honest boundary, stated once and clearly: an address can be perfectly formed and still not receive mail. The mailbox may not exist; the domain may have no mail exchanger; the server may accept everything during the SMTP transaction and silently discard (catch-all servers); the account may be over quota or abandoned. Determining any of that requires network conversation with the recipient's mail infrastructure — SMTP probing and DNS MX lookups — which is a live, third-party-involving operation, and it is what paid verification services actually sell.

Why not do it client-side? Because SMTP verification from a browser is not possible, and doing it from any client means connecting to thousands of third-party mail servers while claiming to represent the sender — the exact behavior spam filters watch for, and the reason reputable verification vendors exist as infrastructure with warmed IP reputations. A free browser tool claiming to verify existence is either doing MX lookups through someone's API (your list is now on that API's logs) or simply lying. We do neither.

What syntax cleaning still buys you is the majority of the damage. ESPs distinguish hard bounces (permanent — unknown user, invalid domain) from soft ones (temporary — full mailbox, greylisting). The address-shaped garbage in a list is what produces hard bounces, and hard bounces are the metric that drags sender reputation. Cleaning syntax and duplicates before a send removes most hard-bounce sources from a typical neglected list — the remaining soft risk is a normal operational cost of email, not a list-quality emergency.

The corner cases that separate a considered cleaner from a regex in a textbox:

• Subdomains: mail.example.com and example.com are different domains — bill@mail.example.com is not a duplicate of bill@example.com, and over-aggressive domain collapsing is a classic cleaner bug.
• Internationalized addresses: addresses with accented local parts or IDN domains (Unicode) are valid and deliverable. A cleaner limited to ASCII wrongly invalidates real customers — ours handles UTF-8 forms, flagging only what the RFC family genuinely forbids.
• Quoted local parts: "john doe"@example.com is legal per RFC 5322, vanishingly rare in the wild, and accepted here with a note. Most tools reject it outright; rejection is defensible, silent acceptance without a flag is not.
• Numeric TLDs and new gTLDs: dave@company misses a TLD, but dave@company.technology is valid — the cleaner checks structure, not an allowlist of known TLDs, so new extensions never invalidate real mail.
• The trailing dot and space family: alice@company.com. (trailing period) and alice@company.com , (comma from CSV export) are damage, not addresses — trimmed, flagged, recoverable.
• CSV column confusion: a full CSV where the email column is misidentified (name column selected instead) produces a 100% invalid rate — obvious, but worth knowing the report makes it obvious rather than emitting an empty clean file and a shrug.

The recurring theme: flag, don't guess. Every ambiguous case becomes a labeled row in a report file rather than a silent decision. A cleaner that decides quietly is a tool that will eventually eat a customer silently, and email lists are precisely the wrong place for that trade.

The people who arrive at this page, by volume:

• Small-business marketers cleaning lists before an ESP import — the core audience, usually fighting a legacy list accumulated across years and forms.
• CRM administrators preparing a migration, where the target system rejects duplicates and malformed addresses at import time and fails loudly.
• Event organizers cleaning registration exports before sending schedules and reminders — one duplicate means one attendee gets the reminder twice and replies twice.
• Teachers and PTA coordinators with parent-contact spreadsheets, where the stakes are annoyance rather than deliverability but the mistakes are identical.
• Newsletter authors of every size, for whom a bounce spike from a stale segment is the difference between an inbox and a spam folder.
• Developers seeding test environments, using the cleaner to generate a deduplicated fixture from a production-shaped export.

The unifying situation is always a list that grew organically and now faces a send or an import. Lists that are cleaned at collection time — good forms, double opt-in — never need this tool. The rest of us have history, and history needs a broom.

The commercial space around email cleaning is large, mature, and priced per thousand addresses. The honest comparison, because the paid tools are not wrong — they are a different job:

The privacy row is not a marketing flourish — it is a genuine decision axis. Upload-based cleaning means your entire customer contact list becomes a file on a third party's systems, governed by their retention terms. For a client list under an NDA, or a patient or student roster, that trade can be disqualifying regardless of the vendor's reputation. Local processing keeps the list's blast radius at zero, and the syntax-and-duplicate layer — which is most of the damage — still gets done.

Round out the workflow with the neighbors: the CSV Deduplicator for whole-row dedupe when the list carries full records, the CSV Distinct Values Extractor for seeing the unique domains and providers in a list before segmenting, and the Email Obfuscator for the moment the cleaned addresses need to appear on a public web page without becoming scraper bait.

Worth saying twice, because this tool's entire reason for existing client-side is the sensitivity of what it processes: your email list is your customer roster. Parsing, dedupe, typo detection and export all run as JavaScript in your browser tab. There is no upload endpoint, no server-side batch queue, no analytics on the addresses you clean. The network tab stays silent through a full 100,000-row clean — the kind of verification we actively encourage people to run.

For the privacy-mandatory cases — lists under GDPR, HIPAA-adjacent communications, NDA'd client rosters — the property is decisive: there is no processor to add to your records, no subprocessor chain, no data-processing agreement. The computation happens where the data already lives, which is the only place it needs to happen for syntax and duplicates. The one part of cleaning that genuinely requires network infrastructure — existence verification — is the part this tool honestly declines to fake.

The questions that arrive whenever lists and bounces meet.

Cleaning is one station in a longer line. Deduplicate full customer rows with the CSV Deduplicator; segment the cleaned list by domain or provider with the CSV Distinct Values Extractor; and when clean addresses must go onto a public page, obfuscate them first with the Email Obfuscator so scrapers harvest noise instead of your customers.