Re-save a garbled CSV as UTF-8 with a BOM so Excel opens it correctly
A CSV is plain text and carries no record of the encoding it was written in. Excel opens it with the system legacy encoding by default, so a UTF-8 file written by a web service or a script comes out wrong. That pairing is the most common cause of the problem.
A BOM (Byte Order Mark) is a marker at the start of a file. In UTF-8 it is the three bytes EF BB BF and it is invisible as text. Excel reads a file as UTF-8 when it finds one, so adding it fixes the display without changing any of the content.
When a program reads the CSV, the BOM can end up inside the first column value and break parsing. Choose the BOM-less output whenever the file is not destined for Excel.
A BOM is trusted when present. Otherwise the file is decoded as UTF-8, Shift_JIS and EUC-JP in turn, and the candidate with the fewest undecodable positions wins. When nothing decodes cleanly the tool says so rather than guessing.
When Excel opens a CSV it reads it as UTF-8 if the file starts with a BOM (the three bytes EF BB BF). A UTF-8 CSV without a BOM may be read as the system's legacy encoding instead, and that is where the garbling comes from.
No. The file is only read. The converted content is downloaded as a separate file and the original is left untouched.
No. Reading, detection, conversion and download all happen inside your browser.
Yes. Short files, or content that decodes cleanly under several encodings, cannot be told apart. The tool reports how many positions failed to decode, so pick the encoding manually when that count is not zero.