Salesforce Data Loader: Fixing “Invalid CSV File Format” and UTF-8 Errors

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

The quick answer: Data Loader’s “CSV Error: Invalid CSV file format” is almost always one of three things: a hidden UTF-8 byte order mark (BOM) at the very start of the file, a delimiter Data Loader isn’t configured to accept, or a file that isn’t really plain-text CSV at all — a renamed .xlsx is the classic. The fix is correspondingly short: save the file as UTF-8 without a BOM, tick Read all CSVs with UTF-8 encoding in Data Loader’s Settings, and make sure the delimiter options match what actually separates your fields. Broken accents after a load — é arriving in Salesforce as é — are the same encoding disagreement, just surfacing one step later.

Why does Data Loader say “CSV Error: Invalid CSV file format”?

Because its very first parse of the file failed — and the message is generic, covering several unrelated faults. Data Loader reads your CSV’s bytes, decodes them with whatever encoding its settings dictate, then splits the text on the delimiters it accepts; a failure at any of those stages produces the same error, which is why the fix that worked for a colleague may do nothing for you. Match your exact symptom first:

How does a UTF-8 BOM cause the “Invalid CSV file format” error?

A byte order mark is a marker some programs write at the very start of a UTF-8 file to announce its encoding. Here is the irony that catches Salesforce admins: Excel’s “CSV UTF-8 (Comma delimited)” save option — the one you pick specifically to do encoding right — always writes a BOM. So the more carefully you saved the file, the more likely Data Loader is to choke on it, a failure documented over and over in Trailblazer community threads and on Salesforce Stack Exchange.

A UTF-8 byte order mark is exactly three bytes — EF BB BF — and those three invisible bytes can sink a Data Loader job of any size, right up to the 150 million records Salesforce supports with Bulk API 2.0.

The mechanics depend on your settings. With Read all CSVs with UTF-8 encoding unchecked, Data Loader decodes the file with your machine’s default code page — usually Windows-1252 — and the three BOM bytes decode as the visible characters , welded to your first column header: Id is suddenly Id, which matches nothing. With the setting checked, older builds could still trip, because Java’s own UTF-8 decoder famously does not strip the BOM — the invisible U+FEFF stayed glued to the first header, a column that looks exactly like Id but fails every comparison against it. Current Data Loader builds do strip it — the CSV reader now opens the file through a BOM-aware stream — but only when it is already reading with a Unicode charset, and Salesforce’s own knowledge base still lists the BOM as a cause of this error. Do not rely on it.

The reliable fix works on every version: give Data Loader a UTF-8 file with no BOM. In Notepad++ that is Encoding → Convert to UTF-8, then save; in VS Code, Save with Encoding → UTF-8. Every CSVUndo tool has an Add UTF-8 BOM (for Excel) checkbox on export — leave it unchecked for Data Loader files. The full story of when a BOM helps and when it hurts is in our UTF-8 BOM and Excel guide.

Which encoding settings should I use in Data Loader?

Both UTF-8 boxes, checked, always. Open Settings from Data Loader’s menu and tick Read all CSVs with UTF-8 encoding and Write all CSVs with UTF-8 encoding. Salesforce itself stores text as Unicode, so the platform is never the weak link — the desktop file step is. With the read setting off, Data Loader guesses your operating system’s default code page, and that guess silently mangles every multi-byte character in a UTF-8 file — é in, é stored. The write setting matters in the other direction: it guarantees exports come out as UTF-8, so accents survive into the file.

One warning about exports: a UTF-8 export that you then double-click opens in Excel as ANSI, and every café on the sheet becomes café — the file is fine, Excel is misreading it. Open exports via Data → From Text/CSV with File Origin set to 65001: Unicode (UTF-8) instead; the byte-level detail is in our é instead of é guide.

And a limit worth being honest about: these checkboxes only control how Data Loader reads and writes files from now on. They cannot repair text that was already decoded wrongly and saved — that damage is baked into the file and needs an actual repair pass.

Why did special characters turn into é or ? after import?

The two symptoms look similar and could not be more different. Mojibake — é, ’, ü clusters — means a UTF-8 file was decoded as ANSI somewhere. Every original byte still exists; the text is being viewed through the wrong lens, and the file is fully reversible. If the damage has already been loaded into Salesforce, the cure is mechanical: repair the source file, then re-import the affected rows as an update keyed on Id, overwriting the mojibake with the correct text. Our broken-characters fixer reverses the standard UTF-8-read-as-ANSI substitutions automatically and leaves already-clean rows untouched.

Literal question marks are the unrecoverable case. A ? where an accent should be means the file passed through a plain ANSI save — usually Excel’s ordinary “CSV (Comma delimited)” format — and characters with no slot in Windows-1252 were replaced at that moment. The original bytes no longer exist in the file, so no tool, ours included, can bring them back. Re-export from the system of record and keep the file UTF-8 this time; the same triage appears in CSV shows question marks instead of letters.

Why does Data Loader read my whole row as one column?

The file’s delimiter and Data Loader’s settings disagree. Excel on a machine with European regional settings saves “CSV” files delimited by semicolons, because the comma is the decimal separator there. Data Loader, by default, splits on commas; point it at a semicolon file and every row arrives as one long field, the mapping dialog offers a single absurd column, and the load dies. Tab-delimited exports from other systems fail the same way.

Two clean exits. In Data Loader’s Settings, the delimiter options let you choose which characters count — comma, tab, and other characters you specify — so you can simply add the semicolon. Or normalise the file instead: our CSV ⇆ TSV converter detects the incoming delimiter automatically and rewrites the file comma-delimited, with quoting handled correctly. Why your Excel writes semicolons at all is covered in Excel saves CSV with semicolons; the one-column symptom has its own guide too: CSV opens with all data in one column.

Which field-mapping traps break a Data Loader import?

Suppose the file finally parses. Mapping is where the quieter faults surface:

• The BOM, again. If auto-matching maps every column except the first, suspect U+FEFF welded to that first header. The header looks identical to Id or Email but is one invisible character longer.
• Whitespace in headers. Email  with a trailing space will not auto-match Email. Trim header names before blaming the mapping file.
• Stale .sdl mapping files. A saved mapping references column names from the day it was created. Rename one header upstream and the mapping silently drops that field — check the mapping dialog rather than trusting last month’s file.
• Excel-damaged values inside the data. Salesforce’s own 15- and 18-character record IDs contain letters, so Excel leaves them alone. Purely numeric external IDs are not so lucky: Excel keeps only 15 significant digits, so a 16+ digit ID is rounded the moment the file opens, the trailing digits become zeros, and once the file is saved those digits are unrecoverable — no tool can restore them, and the only fix is re-exporting from the source, as explained in Excel turned my 16-digit numbers into zeros.
• Scientific notation. Long numbers saved back by Excel as 1.23457E+11 can be expanded to digit form with our scientific-notation fixer — but never assume a value is Excel damage on shape alone. 2E5 is a perfectly plausible real part number, which is why the tool checks context instead of blindly expanding everything that looks exponential. And expansion honestly cannot exceed what Excel kept: digits it already rounded away past the 15th significant place are gone from the file.

What should I check before hitting Insert?

Sixty seconds here beats an hour of deleting half-imported records:

1. Confirm the file is genuine plain-text CSV — exported, not renamed from .xlsx.
2. Run it through the encoding checker: you want UTF-8, no BOM, and no mojibake flag.
3. In Data Loader’s Settings, tick both Read and Write all CSVs with UTF-8 encoding, and confirm the delimiter options match the file.
4. Open the mapping dialog and check the first column mapped — the BOM trap always hits column one.
5. Spot-check ID columns for trailing zeros or E+ notation before loading, not after.
6. Test with a five-row file first. Every failure above reveals itself just as clearly on 5 rows as on 500,000 — and is considerably cheaper to clean up.

Frequently asked questions

Sources: Salesforce’s Data Loader guide documents the UTF-8 read/write settings and the comma, tab and other-delimiter options, and Salesforce’s Data Loader download page states support for up to 5 million records with Bulk API and 150 million with Bulk API 2.0; the BOM failure mode is documented by Salesforce itself in knowledge article 000383918. Java’s refusal to strip the UTF-8 BOM is long-standing, documented JDK behavior — bug JDK-4508058, closed “Won’t Fix”.