Email List Normalizer
Paste a list of email addresses to deduplicate, strip Gmail dots and plus aliases, lowercase, and validate format. Download the cleaned list.
Last reviewed: April 2026New to this tool? Click here for instructions
How to Use the Email Normalizer
To use the Email List Normalizer, simply paste a list of email addresses into the input area. The tool handles lists formatted as one email per line, comma-separated, or semicolon-separated. Choose the normalization options you need, such as stripping Gmail dots, removing plus aliases, and validating email formats. Click 'Normalize' to see the cleaned list and statistics on duplicates and invalid addresses.
When to Use the Tool in Real Workflows
The Email List Normalizer is ideal for anyone who needs to clean and deduplicate email lists for email marketing, database imports, or analytics. It's particularly useful when dealing with data collected from forms, spreadsheets, or data exports where duplicates and format inconsistencies are common.
How It Works
The Email List Normalizer tool applies several normalizations to your email list. It removes Gmail dots from the local part of Gmail addresses, strips plus aliases, and validates email addresses against a standard format regex. The tool also counts duplicates and invalid addresses, providing a clean list and detailed statistics.
Tips, Edge Cases, and Limitations
Note that format validation cannot determine if an address is active or if the mailbox exists - for that, you would need SMTP verification, which requires a server. The tool does not support internationalized email addresses (RFC 6531).
Frequently Asked Questions
Paste or upload a bulk email list to deduplicate, validate format, and collapse Gmail dot and plus-address aliases in one pass. The tool lowercases every address, applies provider-specific alias rules, strips subaddress tags (configurable), rejects RFC 5322 violations, and outputs a clean list with a summary of exactly what changed.
What This Tool Does
The Email List Normalizer applies a sequence of transformations to every address in your list, then removes duplicates on the resulting canonical form. Specifically, it: lowercases all addresses; strips Gmail dot aliases so that john.doe@gmail.com and johndoe@gmail.com collapse to a single entry (per Gmail's own documented behavior); removes plus-address suffixes — john+newsletter@gmail.com becomes john@gmail.com — as a configurable option; deduplicates after normalization so addresses that looked different in the raw list but map to the same inbox are counted once; flags addresses that violate RFC 5322 format rules (consecutive dots, missing @, no domain) and optionally removes them from output; and exports the cleaned list as plain text, one address per line, or as a CSV column. Everything runs in your browser — no addresses leave your machine.
How to Use It
Step-by-step instructions
- Paste or upload your list. Drop addresses into the input area, one per line, or paste a single-column CSV. The tool accepts any mix of spacing and blank lines.
- Choose normalization options. Three toggles control behavior: Gmail dot stripping (ON by default) collapses dot variants for
@gmail.comand@googlemail.com; Plus-address stripping (ON by default) removes the+tagsuffix from all providers; Remove invalids (ON by default) excludes RFC 5322-violating addresses from the output and lists them separately. - Click Normalize. Processing is instant for typical list sizes.
- Review the summary stats. Four cards show: input count, output count, duplicates collapsed, and invalids flagged — enough to gauge data quality before you use the list.
- Copy or download the cleaned list. Use the Copy button for quick clipboard export or Download to save a
.txtor.csvfile. To prepare a file before pasting it here, the CSV Formatter can extract a single column from a multi-column spreadsheet export.
The Try Example button loads the seed list below automatically so you can verify the tool's behavior before pasting your own data.
Worked example walkthrough
Starting with the following 10 raw addresses:
- Input (one address per line)
-
john.doe@gmail.com john+newsletter@gmail.com JOHN+PROMOS@GMAIL.COM johndoe@gmail.com jane_smith@outlook.com JANE.SMITH+ALERTS@OUTLOOK.COM jane_smith@outlook.com invalid..format@example.com sarah@company.org sarah+test@company.org
Here is what happens at each stage:
- Trim whitespace and lowercase. All 10 addresses are lowercased.
JOHN+PROMOS@GMAIL.COMbecomesjohn+promos@gmail.com;JANE.SMITH+ALERTS@OUTLOOK.COMbecomesjane.smith+alerts@outlook.com. - RFC 5322 validation.
invalid..format@example.comfails — consecutive dots in the local part are prohibited by RFC 5322 §3.4.1. It is flagged and removed. The remaining 9 addresses pass. - Gmail dot stripping. For
@gmail.comaddresses, dots in the local part are removed.john.doe@gmail.com→johndoe@gmail.com. The plus-tag addresses are unchanged at this step because dot stripping runs on the local part before the+separator:john+newsletter@gmail.com→john+newsletter@gmail.com(no dots to strip). - Plus-address stripping (option ON). The
+tagsuffix is removed from all providers:john+newsletter@gmail.com→johndoe@gmail.com;john+promos@gmail.com→johndoe@gmail.com;jane.smith+alerts@outlook.com→jane.smith@outlook.com;sarah+test@company.org→sarah@company.org. - Outlook dot rule does NOT apply.
jane_smith@outlook.comandjane.smith@outlook.comremain distinct normalized strings because Outlook treats dots as significant. - Deduplication.
johndoe@gmail.comnow appears from rows 1, 2, 3, and 4 — collapsed to 1.jane_smith@outlook.comappears from rows 5 and 7 — collapsed to 1. - Final output: 4 unique canonical addresses plus 1 flagged invalid. Summary: 10 inputs → 4 outputs, 3 duplicates/aliases collapsed, 1 invalid removed.
johndoe@gmail.com
jane_smith@outlook.com
jane.smith@outlook.com
sarah@company.org
(1 invalid flagged: invalid..format@example.com — consecutive dots in local part)
(Plus-address stripping ON; Gmail dot stripping ON; 4 unique addresses from 10 inputs; 3 duplicates/aliases collapsed; 1 invalid removed)Before vs. After: 10-Row Normalization Example
| Raw Input | Normalized Output | Action Taken |
|---|---|---|
john.doe@gmail.com |
johndoe@gmail.com |
LOWERCASED, DOT-STRIPPED |
john+newsletter@gmail.com |
johndoe@gmail.com |
PLUS-STRIPPED, DEDUPLICATED (group 1) |
JOHN+PROMOS@GMAIL.COM |
johndoe@gmail.com |
LOWERCASED, PLUS-STRIPPED, DEDUPLICATED (group 1) |
johndoe@gmail.com |
johndoe@gmail.com |
LOWERCASED, DEDUPLICATED (group 1) |
jane_smith@outlook.com |
jane_smith@outlook.com |
LOWERCASED |
JANE.SMITH+ALERTS@OUTLOOK.COM |
jane.smith@outlook.com |
LOWERCASED, PLUS-STRIPPED (distinct from row 5) |
jane_smith@outlook.com |
jane_smith@outlook.com |
LOWERCASED, DEDUPLICATED (group 2) |
invalid..format@example.com |
— FLAGGED INVALID — | INVALID-FLAGGED (consecutive dots, RFC 5322 §3.4.1) |
sarah@company.org |
sarah@company.org |
LOWERCASED |
sarah+test@company.org |
sarah@company.org |
PLUS-STRIPPED, DEDUPLICATED (group 3) |
johndoe@gmail.com; rows 5 and 7 to jane_smith@outlook.com; rows 9 and 10 to sarah@company.org. Row 8 is rejected per RFC 5322.How Email Normalization Works
Normalization runs as a three-stage pipeline. Understanding each stage helps if you want to replicate the logic in application code or audit the tool's output.
Stage 1: Case folding
RFC 5321 §2.4 specifies that the local part of an email address is technically case-sensitive — John@example.com and john@example.com could be different mailboxes. In practice, no major provider enforces this distinction, and treating mixed-case addresses as equivalent is the safe default for list hygiene. The tool lowercases the entire address — local part and domain — before any other step. This single transformation eliminates a large class of apparent duplicates without any provider-specific knowledge.
Stage 2: Alias collapse
After case folding, provider-specific rules run. Gmail dot stripping applies only to addresses whose domain is @gmail.com or @googlemail.com; all dots in the local part are removed. Plus-address stripping — defined by RFC 5321 §4.1.2's subaddress extension — is provider-agnostic: the tool truncates the local part at the first + character, regardless of domain. RFC 5322 §3.4.1 defines the addr-spec syntax; addresses that fail the consecutive-dot prohibition or lack a valid structure are flagged at this stage rather than silently passed through.
Stage 3: Deduplication
Deduplication runs on the normalized string produced by stages 1 and 2. Two raw addresses are duplicates only when their normalized forms are identical — the tool never collapses addresses that happen to share a base local part but belong to different providers. The first occurrence of each normalized address is kept; all later occurrences are removed and counted in the summary. That deduplication count gives you a direct measure of alias inflation in the original list.
Gmail Dots and Plus Addressing Explained
Gmail dot handling
Gmail officially documents that dots in the local part of an address are ignored: john.doe@gmail.com, johndoe@gmail.com, and j.o.h.n.d.o.e@gmail.com all deliver to exactly the same inbox. This is a Gmail-specific product decision, not a requirement of any email standard. RFC 5321 and RFC 5322 make no such provision — dots are syntactically meaningful in the local part under the spec. The tool therefore applies dot stripping exclusively to @gmail.com and @googlemail.com domains and never to other providers.
Plus addressing (subaddressing) across providers
RFC 5321 §4.1.2 defines subaddressing as a valid extension: the receiving MTA may use the tag after + for local routing, or simply ignore it and deliver to the base address. This mechanism is broadly supported — Gmail, Outlook/Hotmail, Yahoo Mail, ProtonMail, Fastmail, and Apple iCloud all honor it. Because the behavior is provider-agnostic, plus-tag stripping applies to every domain, not just Gmail. The option is ON by default because the common bulk-list use case is deduplication, but you can disable it if your downstream system uses tags for routing or audience segmentation.
Why this matters for list hygiene
A user who tracks newsletter opens per campaign might sign up as john+newsletter@gmail.com for one campaign and john+promos@gmail.com for another. Both deliver to the same inbox; both appear as separate contacts in your CRM without normalization. At scale, that alias inflation produces duplicate sends to the same person, skews open-rate metrics, and wastes send quota. Stripping plus tags deduplicates these cases, but it is a business decision rather than a correctness one — there is no guarantee that two addresses sharing a base local part belong to the same human. If separate users in your system legitimately share a base address (a shared inbox with tagged sub-recipients, for example), stripping plus tags will incorrectly merge them. The tool surfaces this trade-off in its options panel rather than hiding it.
Edge Cases: What Gets Normalized and What Doesn't
Addresses the tool normalizes
Leading and trailing whitespace is trimmed silently on every line — a common artifact of copy-pasting from spreadsheets. Mixed-case variations like SARAH@COMPANY.ORG are lowercased to sarah@company.org before any comparison. Gmail addresses with dots anywhere in the local part are stripped: s.a.r.a.h@gmail.com collapses to sarah@gmail.com. Plus tags are removed up to the first + when that option is enabled. Empty lines in the input are silently skipped and do not inflate the input count.
Addresses the tool flags as invalid
RFC 5322 §3.4.1 prohibits consecutive dots in the local part, so invalid..format@example.com is rejected. Addresses missing an @ character entirely, those with no domain component, and those exceeding 254 characters (RFC 5321 §4.5.3.1 sets this as the maximum path length) are also flagged. The invalids panel lists each rejected address alongside the specific rule it violated — useful for diagnosing upstream data quality issues.
Addresses the tool leaves unchanged
Quoted local parts such as "john doe"@example.com are valid per RFC 5322 and pass through without modification; the tool does not attempt to normalize quoted strings. Addresses on non-Gmail domains are not dot-stripped: jane_smith@outlook.com and jane.smith@outlook.com remain distinct normalized forms because Outlook treats dots as significant. IDN (internationalized) domains such as user@münchen.de pass through without Punycode conversion — the tool does not perform Unicode normalization on the domain part. If your list contains IDN addresses, validate them separately against your sending platform's requirements.
Behind the Scenes: Normalization Rules and RFC References
The normalization algorithm
Processing runs in a fixed order for each address: trim leading/trailing whitespace → lowercase the full address → validate against RFC 5322 §3.4.1 addr-spec syntax → apply Gmail dot-stripping if the domain is gmail.com or googlemail.com → strip the +tag suffix (if that option is enabled) → add the resulting normalized string to a seen-set for deduplication. Any address that fails RFC 5322 validation is routed to the invalids list before the alias-collapse steps run, so normalization is never applied to malformed addresses. The entire pipeline executes client-side in the browser; no address is transmitted to any external server at any point.
RFC and standards references
The rules the tool implements trace directly to published standards. RFC 5321 §2.4 addresses case sensitivity of local parts. RFC 5321 §4.1.2 defines the subaddress (plus-tag) extension mechanism. RFC 5321 §4.5.3.1 sets the 254-character maximum address length. RFC 5322 §3.4.1 defines the addr-spec production rule and prohibits consecutive dots outside quoted strings. Gmail's dot-ignoring behavior is documented in Google's official Help Center under "Dots don't matter in Gmail addresses" — it is not derivable from any RFC. These sources are the authoritative basis for every decision the tool makes; when a case falls outside them, the address is left unchanged rather than guessed at.
| Rule | Applies To | Configurable | RFC / Source |
|---|---|---|---|
| Case folding (lowercase) | All addresses | No (always on) | RFC 5321 §2.4 (practical convention) |
| Gmail dot stripping | @gmail.com, @googlemail.com |
Yes (default ON) | Gmail Help: "Dots don't matter in Gmail addresses" |
| Plus-address stripping | All providers | Yes (default ON) | RFC 5321 §4.1.2 |
| Consecutive-dot validation | All addresses | Yes (flag/remove invalids) | RFC 5322 §3.4.1 |
| Max-length validation (254 chars) | All addresses | Yes (flag/remove invalids) | RFC 5321 §4.5.3.1 |
| Whitespace trim | All addresses | No (always on) | — |
Email Provider Support Matrix
| Provider | Dots Ignored in Local Part | Plus Addressing Supported | Tool Applies Dot Stripping | Notes |
|---|---|---|---|---|
| Gmail / Google Workspace | ✅ Yes | ✅ Yes | ✅ Yes | Google Help Center explicitly documents dot-ignoring for @gmail.com and @googlemail.com |
| Outlook / Hotmail | ❌ No | ✅ Yes | ❌ No | Dots are significant; jane_smith@outlook.com ≠ jane.smith@outlook.com |
| Yahoo Mail | ❌ No | ✅ Yes (uses - as separator in some regions) |
❌ No | Yahoo supports + for subaddressing; dots are treated as distinct characters |
| ProtonMail | ❌ No | ✅ Yes | ❌ No | RFC 5321-compliant subaddressing; dots are significant per spec |
| Fastmail | ❌ No | ✅ Yes | ❌ No | Fastmail also supports tagged aliases independently of plus addressing |
| Apple iCloud | ❌ No | ✅ Yes | ❌ No | iCloud supports +tag subaddressing; dots in local part are significant |