CSV Cleaner
Repair the encoding, delimiters, and broken rows in a CSV that will not import.
By opening this website or using its tools, you agree to our Terms and Privacy Policy.
paste rows, or drop a .csv file
Encoding is detected by decoding strictly as UTF-8 first; a file that fails that test is almost always Windows-1252 out of Excel, which is what turns “é” into “é”. Whichever was used is named above the output, so a wrong guess is visible rather than silent. Output is always written as UTF-8 with Unix line endings.
Your file never leaves your browser during processing
How it works
To fix a broken CSV, drop the file onto this page — the encoding is detected, rows with the wrong number of fields are repaired, stray whitespace and invisible characters are removed, and every change is listed so you can see exactly what was altered.
A CSV that will not import usually fails for one of four reasons, and this page addresses all four. The encoding is wrong, so accented characters arrive as mojibake. The delimiter is not what the importer expects. Some rows have more or fewer fields than the header. Or the values carry whitespace and invisible characters that break joins and lookups without ever being visible on screen.
Encoding is detected by decoding the bytes strictly as UTF-8 first. That test fails on almost any non-UTF-8 byte sequence, which makes a successful decode strong evidence; when it fails, the file is nearly always Windows-1252 out of Excel, which is what turns é into é. Whichever was used is named above the output, so a wrong guess is visible rather than silent, and the result is always written back as UTF-8.
Rows with the wrong field count are the case where a cleaner can do real damage, so the choice is yours rather than a heuristic’s. Padding short rows and keeping the extras from long ones in overflow columns is the default because it is the only option that cannot lose data. Truncating discards the extra fields. Dropping removes the row entirely. Leaving them alone is also on the list, for when the raggedness is meaningful.
The invisible fixes are the ones worth knowing about: non-breaking spaces from copy-pasted web tables, zero-width characters, and line breaks inside fields all get normalised. These are why "Total " and "Total" refuse to match in a lookup, and why a row count comes out wrong in a way nobody can see. Every repair is counted and the affected row numbers are named, because a cleaner that quietly drops eleven rows is worse than no cleaner at all — you find out much later, somewhere else.
FAQ
Why does my CSV show é instead of é?
It was saved in Windows-1252 and is being read as UTF-8, or the reverse. Drop it here and the encoding is detected, named, and the file rewritten as UTF-8 so the accented characters are correct.
What do I do about rows with too many fields?
Choose how they are handled. The default keeps the extra values in overflow columns so nothing is lost; you can also truncate them, drop the row, or leave it as-is. The report names which rows were affected either way.
How is this different from the CSV formatter?
The formatter validates and reports — it tells you the file is broken. This one changes the file to fix it. They are separate tools because rewriting someone’s data is a different act from checking it.
Can it convert a semicolon file to a comma file?
Yes. Set what to read it as and what to write it as separately; auto-detection handles the reading side if you are not sure.
What are the invisible characters it removes?
Non-breaking spaces, zero-width spaces and joiners, and word joiners — characters that look like nothing but stop values matching in lookups and joins. Line breaks inside a field are collapsed to a space.
Is my file uploaded?
No. It is decoded, repaired, and rewritten in your browser, and the monitor under the tool shows zero bytes sent.