Mailchimp "We Can't Upload That File Type": Every Cause and Fix

8 min readPipeSheets Team

When Mailchimp says 'we can't upload that file type', it has rejected your file before reading a single contact. This is not a field-mapping problem or a bad-email problem; the importer looked at the file itself and decided it is not something it can open. Mailchimp's contact importer accepts CSV and tab-delimited text files, and this error means your file is not one of those, even if its name ends in .csv. That last part is the trap that catches most people: the extension says CSV, but the bytes inside are an Excel workbook, a UTF-16 export, or a zip archive, and Mailchimp believes the bytes, not the name.

The fastest route to a fix is figuring out what your file actually is, and a plain text editor tells you in ten seconds. Below is the full list of triggers, a decision-tree diagnosis, and the concrete fix for each, including how to re-save correctly from Excel, Google Sheets, and Apple Numbers so the error does not come back. If you are past this error and hitting problems inside the import, wrong columns, rejected addresses, mapping confusion, that territory is covered in our general guide to Mailchimp CSV import errors; this post is only about getting the file through the door.

Every trigger of the error

In rough order of how often we see them:

Genuinely wrong extension: you picked an .xlsx, .xls, .numbers, .ods, or .txt file. Spreadsheet formats are not importable directly; they must be exported to CSV first.
An XLSX wearing a .csv name: someone renamed workbook.xlsx to contacts.csv, or an export produced Excel bytes with a .csv label. Renaming changes nothing about the contents.
Wrong text encoding: the file is UTF-16 or another encoding Mailchimp cannot read. Classic source: Excel's older 'Unicode Text' save option, and some CRM exports.
File too large: Mailchimp's importer caps contact files at 60MB (and web uploads in general do not tolerate huge files well). Oversized files get rejected up front.
A zipped or compressed file: contacts.csv.zip, or an export tool that delivered a .zip you never unpacked.
Odd output from Numbers or OpenOffice/LibreOffice: exporting with nonstandard delimiters or encodings can produce a file that is technically text but not a CSV Mailchimp recognizes.

The 10-second diagnosis: open it in a text editor

Do not open the file in Excel to check it; Excel helpfully renders many broken files as normal-looking tables, which hides the problem. Instead open it in a plain text editor: Notepad on Windows, TextEdit on Mac, or VS Code anywhere. What you see tells you which fix you need.

Open the file in a text editor. What do you see?

  email,first_name,last_name
  ana@example.com,Ana,Silva          -> real CSV. Check size (60MB cap)
                                        and encoding (should be UTF-8).

  PK.. followed by binary garbage    -> it is an XLSX (or ZIP) renamed
  and names like [Content_Types].xml    to .csv. Re-export, don't rename.

  Chinese-looking characters, or     -> UTF-16 encoding. Re-save the
  a space between every letter,         file as UTF-8 CSV.
  or the editor asks for an encoding

  One column of text, no commas,     -> tab-delimited or wrong delimiter.
  or semicolons between fields          Usually importable once re-saved
                                        as comma-separated CSV.

  Can't open it / editor says        -> compressed archive. Unzip it and
  it's binary, name ends .zip           import the CSV inside.

The 'PK' tell deserves a note, because it explains the most confusing version of this error. An .xlsx file is actually a ZIP archive of XML files, and every ZIP archive starts with the bytes 'PK' (the initials of Phil Katz, who created the format). When you rename an .xlsx to .csv, the first two characters of the file are still PK, and any tool that checks content, Mailchimp included, immediately knows it is not text. If your 'CSV' starts with PK, no amount of renaming will fix it; the data must be re-exported from the spreadsheet as actual CSV.

Fix 1: You selected a spreadsheet file (.xlsx, .xls, .numbers, .ods)

Mailchimp's contact importer wants delimited text, not a spreadsheet document. Open the file in its native application and export it: in Excel, File > Save As and choose 'CSV UTF-8 (Comma delimited) (*.csv)'; in Numbers, File > Export To > CSV; in LibreOffice Calc, File > Save As with 'Text CSV' and confirm UTF-8 and comma when the options dialog appears. Two extra rules: export only the sheet with your contacts (CSV is single-sheet, and exporters take the active sheet), and make sure row 1 contains your column headers, since Mailchimp uses it for field matching.

Fix 2: An XLSX renamed to .csv

If the text editor showed 'PK' and XML gibberish, someone renamed the file instead of converting it, an extremely common shortcut that never works. Rename it back to .xlsx, open it in Excel or another spreadsheet app, verify the data looks right, and do a genuine Save As to CSV UTF-8 as in Fix 1. If the file will not open even as .xlsx, it may be a plain ZIP; try unzipping it, and you may find the real CSV inside.

Fix 3: UTF-16 or another unreadable encoding

If the editor showed spaced-out letters, asked you to pick an encoding, or displayed what looks like East Asian characters where your contact list should be, the file is most likely UTF-16. Excel's legacy 'Unicode Text (*.txt)' format saves UTF-16 tab-delimited text, and various CRMs and databases export UTF-16 by default. Mailchimp expects UTF-8. The fix is a re-save: open the file in Excel (it usually decodes UTF-16 correctly) and Save As 'CSV UTF-8', or open it in VS Code, use the 'Save with Encoding' command, and choose UTF-8. After re-saving, reopen in the text editor and confirm you now see plain readable rows with commas.

Fix 4: The file exceeds the 60MB import cap

Mailchimp's contact import caps files at 60MB. Contact files rarely get there on names and emails alone; the bloat usually comes from dozens of exported CRM columns you are not importing anyway, or from millions of stale rows. Two moves shrink the file: drop every column Mailchimp will not use (keep email, name, and the merge fields you actually populate), and split the remainder into parts under the cap, imported one after another. Splitting is safe because Mailchimp deduplicates contacts by email address across imports, so overlapping rows update rather than duplicate.

Column-stripping a huge export is painful in Excel, which gets sluggish exactly when files get big. PipeSheets handles this well within its file limits: upload the CSV, drop the columns you do not need, trim whitespace, normalize the headers, and download a much smaller file, with a preview of the result before you commit. The free tier covers files up to 25MB, and a saved pipeline means next month's export gets the same one-click treatment. PipeSheets will not split a file into parts, but after dropping unneeded columns most contact files no longer need splitting at all.

Fix 5: The file is zipped

Export tools love delivering data as contacts.zip, and a compressed archive is not an importable file type. Unzip it first: double-click on Mac, right-click > Extract All on Windows, then import the .csv found inside. Watch for the double-trap: some archives contain an .xlsx, which sends you back to Fix 1 after extraction. And if hidden extensions are on in Windows, a file shown as 'contacts.csv' may really be 'contacts.csv.zip'; turn on file name extensions in Explorer's View menu to see the truth.

Fix 6: Tab-delimited, semicolon-delimited, or Numbers/OpenOffice oddities

If the text editor shows readable rows but the fields are separated by tabs or semicolons instead of commas, you have a delimiter issue. Tab-delimited text is usually fine, since Mailchimp accepts tab-delimited files alongside CSV, but semicolon-separated files, which Excel produces on systems using European regional settings where the comma is the decimal separator, are a common reject. Exports from Numbers and older OpenOffice versions can also carry unusual delimiter or encoding combinations. The universal fix is a round-trip through Google Sheets: import the file (Sheets detects nearly any delimiter automatically), check the columns split correctly, then download as Comma Separated Values. That single pass normalizes the delimiter, the encoding, and the line endings in one step.

Re-saving correctly, once and for all

The known-good export path from each tool:

Excel (Windows and Mac): File > Save As > 'CSV UTF-8 (Comma delimited) (*.csv)'. Avoid the legacy plain 'CSV (Comma delimited)' option when you have accented names, and never 'Unicode Text', which is the UTF-16 trap.
Google Sheets: File > Download > 'Comma Separated Values (.csv)'. Sheets always writes UTF-8, which makes it a reliable laundering step: import a problem file into Sheets, then download as CSV.
Apple Numbers: File > Export To > CSV, and check Advanced Options to confirm Unicode (UTF-8). Never share the .numbers file itself; it is a package format no importer reads.
LibreOffice / OpenOffice Calc: File > Save As > 'Text CSV', then in the options dialog set character set UTF-8, field delimiter comma, and text delimiter double quote.

After any re-save, run the text-editor check one final time: readable rows, commas between fields, headers on line 1, and a file size under 60MB. A file that passes that inspection sails through Mailchimp's file-type gate. Whatever happens after that, unmatched columns, rejected rows, tag questions, is import-content territory rather than file-type territory, and our broader Mailchimp import errors guide picks up exactly there.

The 'we can't upload that file type' error looks opaque, but it is the most mechanical failure in the whole import chain: the bytes in the file do not match the .csv promise on the label. Check the bytes in a text editor, apply the matching fix, re-export properly from your spreadsheet tool, and the error disappears for good.