Mailchimp Rejected Your Contact CSV? Fix the Encoding and the Delimiter

Last updated: August 2026 · By the CSVUndo team · 8 min read

Mailchimp rejects or garbles a contact CSV for two reasons far more often than any other: the file is not UTF-8, or it is not really comma-separated. Mailchimp accepts comma-separated CSV or tab-delimited TXT files and expects UTF-8 text — while Excel’s default “CSV (Comma delimited)” save writes the legacy Windows-1252 encoding, and on European-locale machines it writes semicolons instead of commas. Re-save the list as CSV UTF-8 with commas — or convert it in your browser with the free tools below — and the same file imports cleanly, with Müller spelled correctly.

Why did Mailchimp reject my CSV import?

Match your symptom before touching the file — the failures look similar but have different fixes. Mailchimp’s importer makes two silent assumptions about every file you upload: the bytes are UTF-8, and the fields are separated by commas. When either assumption is wrong, you get one of the failures below. Three of them are fixable in a minute; one means the data is already gone and no tool can help.

The last row deserves emphasis because it is the one honest limit of every repair tool: once a program has written a literal ? in place of a character, the original bytes no longer exist in the file, and nothing can reconstruct them. That case is covered in detail in CSV shows question marks instead of letters. Everything else on this page is genuinely reversible.

Why does Mailchimp turn Müller into M?ller?

Because your file was ANSI and Mailchimp read it as UTF-8. In Windows-1252, ü is stored as the single byte 0xFC. In UTF-8, that same letter is two bytes, 0xC3 0xBC, and a lone 0xFC is not a legal UTF-8 sequence at all. When a UTF-8 decoder hits that byte it cannot interpret it, so it substitutes the Unicode replacement character � — which many fonts and tables then draw as a plain question mark. Müller goes in; M?ller comes out. The same happens to José, François, and every € in a notes column.

Windows-1252 can represent at most 256 characters, while UTF-8 — the encoding Mailchimp expects — covers more than 1.1 million, so every contact name outside those 256 legacy slots is at risk each time Excel saves your list as plain CSV.

The crucial reassurance: the damage happened during Mailchimp’s decode, not inside your file. The CSV on your computer almost certainly still says Müller, byte-perfect. Nothing needs retyping — hand Mailchimp the same data in the encoding it expects. Unsure what your file actually is? Check the CSV’s encoding first, then follow changing a CSV’s encoding to UTF-8. Because Mailchimp matches contacts by email address, re-importing the corrected file with Update any existing contacts ticked overwrites the garbled names in place — but include every column you need, because Mailchimp warns that blank fields overwrite and erase existing contact data.

What if the file shows Müller before you even upload?

That is the mirror-image accident, and it is fully reversible. Here the file started life as UTF-8 — a CRM export or a previous Mailchimp download — and somebody double-clicked it into Excel, which assumed ANSI, showed Müller, and saved. The garble, called mojibake, is now real text inside the file, and Mailchimp will import it exactly as written. But because every ü pair corresponds to exactly one original ü, it can be undone losslessly — even double-encoded monsters like é.

The CSVUndo broken-character fixer does this the strict way rather than with find-and-replace lists. Each suspicious cell is mapped back to the Windows-1252 bytes it came from, and those bytes are accepted only if they decode as completely valid UTF-8; otherwise the cell is left byte-for-byte untouched. That strictness matters for contact lists: Ã and ã are legitimate letters in Portuguese names, so a genuine João fails the reversal test and passes through unchanged. A helpful side effect: the repaired file always downloads as UTF-8, so even a plain ANSI file with no mojibake comes out Mailchimp-ready. The byte-level walkthrough lives in why é appears instead of é.

Why is my semicolon CSV all in one column in Mailchimp?

Because Mailchimp splits fields on commas, and your file has none. On any Windows system whose regional format uses a decimal comma — Germany, France, Spain, Italy, the Netherlands, most of South America — Excel’s plain CSV save uses semicolons as the field separator, since commas are already taken by numbers like 3,14. The file is perfectly valid on your machine and opens beautifully in your Excel. Mailchimp, however, looks for commas, finds none, and treats each entire line as one giant field: the mapping screen shows a single column containing Anna;Müller;[email protected];Berlin, and the import stalls because no column can be identified as the email address.

The fix is a delimiter conversion, not retyping: the CSV ⇆ TSV converter auto-detects the semicolons, previews the table so you can confirm the columns split correctly, and writes a comma-separated copy — quoting any field that genuinely contains a comma, so “Berlin, Germany” survives intact. Why Excel does this at all is covered in Excel saves CSV with semicolons; the mirror-image mismatch is in CSV opens with all data in one column, and if your list also carries decimal-comma numbers, read European number formats in CSV before converting.

How do I fix Mailchimp column mapping failures?

Mapping fails when Mailchimp cannot find clean headers and an email column — and the causes are almost always in the first two lines of the file. Work through this checklist in order:

1. Check the delimiter first. If everything is in one column, no amount of header fixing helps — convert semicolons to commas as described above.
2. Delete any sep=; or sep=, line. Some tools add this hint line for Excel’s benefit. Excel understands it; Mailchimp does not, and it becomes a bogus first row that shifts every mapping by one.
3. Exactly one header row. A title line above the headers, or a repeated header row from a copy-paste merge, makes Mailchimp offer nonsense field names. The first line of the file should be the column names and nothing else.
4. No blank or duplicate header cells. Every column Mailchimp is supposed to import needs a distinct, non-empty name; unnamed trailing columns (often left over from a stray Excel cell) are best deleted before export.
5. One column must contain plain email addresses. Mailchimp requires an email address field for every email contact — the only exception is an SMS-only import, which needs an E.164 phone number instead. If addresses are wrapped in display names like Anna Müller <[email protected]>, strip them to the bare address.

After those five, the mapping screen should show each field in its own column with sensible names, and the import proceeds.

How do I save a contact CSV that Mailchimp will accept?

Choose the UTF-8 variant every time, and never trust a double-click. The routine that prevents this whole page from happening again:

1. Finish the list in Excel, accents and all.
2. Open File → Save As → Browse, and in Save as type pick CSV UTF-8 (Comma delimited) (.csv) — not the plain CSV (Comma delimited) entry next to it. Excel 2016 and later all have it; the full walkthrough is in saving Excel files as CSV UTF-8.
3. On a European locale, open the saved file in Notepad and check the first line. Semicolons? Run it through the converter before uploading.
4. When you download an audience export from Mailchimp, never double-click it into Excel — that is how UTF-8 becomes Müller. Use Data → From Text/CSV with File Origin set to 65001: Unicode (UTF-8).

If your Excel predates the CSV UTF-8 option, Google Sheets is the simplest escape hatch: it reads and writes UTF-8 with comma delimiters at every step, which happens to be exactly Mailchimp’s format.

A warning about phone numbers and long IDs in contact files

Encoding damage is reversible; digit damage usually is not. Contact CSVs carry more than names — phone numbers, customer IDs, loyalty-card numbers. Excel treats any bare digit string as a number, keeps only 15 significant digits, and shows long values in scientific notation. A 16-digit ID that Excel truncated to 15 significant digits and saved has had its final digits replaced with zeros permanently — they are unrecoverable, by our tools or anyone else’s, and the only fix is re-exporting from the source. See 16-digit numbers changed to zeros and phone numbers broken in CSV for the prevention steps.

Display-only scientific notation, by contrast, often can be undone — but never on shape alone. A cell reading 2E5 might be Excel’s mangling of a number, or it might be a genuine part code or postcode fragment; expanding it on a guess would rewrite real customer data, which is why the scientific notation fixer only converts values it can prove came from Excel’s formatting and asks you to confirm the rest.

Frequently asked questions

Sources: Mailchimp’s guidance on international characters states that Mailchimp relies largely on UTF-8, and its contact-import troubleshooting page warns that some European spreadsheet programs use semicolons rather than commas and tells you to replace them with commas before importing. The M?ller and one-column symptoms follow directly from decoding Windows-1252 bytes as UTF-8 and from splitting semicolon rows on commas. Browse the CSVUndo guides index for related fixes.