CSV troubleshooting
How to Fix Garbled Characters (Mojibake) in a CSV File
Garbled CSV text is almost always an encoding mismatch, not lost or corrupted data: the file was saved in one character encoding (commonly Windows-1252/ANSI from Excel, or occasionally UTF-16) and is being read back as a different one (commonly UTF-8). The underlying bytes are usually still intact. Re-save or export the source file as UTF-8, re-check a few known accented, currency, or punctuation values, and confirm the header row has no stray character glued to the first column name before treating the file as clean.
Short answer
Garbled CSV text is almost always an encoding mismatch, not lost or corrupted data: the file was saved in one character encoding (commonly Windows-1252/ANSI from Excel, or occasionally UTF-16) and is being read back as a different one (commonly UTF-8). The underlying bytes are usually still intact. Re-save or export the source file as UTF-8, re-check a few known accented, currency, or punctuation values, and confirm the header row has no stray character glued to the first column name before treating the file as clean.
Upload
Bring the CSV you already use.
Understand
Start with the brief and evidence.
Act
Ask, edit, filter, and export.
Start with the safe answer
Garbled text such as Café instead of Café, or don’t instead of don't, is a sign that the file's bytes are being decoded with the wrong character encoding — not that the original data is gone. Before editing anything, keep the original file untouched and work on a copy. Identify the source encoding, re-save or re-export as UTF-8, and re-verify a sample of affected values. Do not manually "correct" garbled characters one by one inside a spreadsheet. That fixes the visible symptom in one view while leaving the underlying bytes mismatched, and it does not scale past a handful of rows.
Recognize mojibake versus real data loss
Two different problems look similar but need different fixes: Mojibake (encoding mismatch): individual accented letters, apostrophes, quotation marks, or currency symbols render as odd character sequences, while the rest of the row (numbers, plain ASCII text, row count) looks normal. This is a decoding problem and is generally recoverable. Real data loss or truncation: entire fields are blank, cut off mid-word, or rows are missing compared to the source system. This is not an encoding issue and needs a different investigation, such as a failed export, a dropped column, or a parsing error on unescaped delimiters. If only non-ASCII characters look wrong and row/column counts otherwise match the source, treat it as an encoding mismatch first.
Know the common source encodings
Most CSV encoding problems trace back to a small set of causes: Windows-1252 / ANSI: the classic cause of Café becoming Café. Common when a CSV was saved from an older or default "CSV (Comma delimited)" export on Windows and is later read as UTF-8. UTF-8 with BOM: a valid UTF-8 file that starts with an invisible byte-order-mark. Handled correctly by most modern tools, but tools that do not strip it can show a stray character glued to the first header, such as OrderID instead of OrderID. UTF-16: produced by some "Unicode Text" export options. Reading a UTF-16 file with a UTF-8 decoder typically produces mostly unreadable output with frequent replacement characters, not just a few wrong letters. Legacy or regional encodings (e.g., Shift-JIS, ISO-8859-1, GBK): common in older systems or non-English locales; symptoms vary by encoding but follow the same root cause — the writer and reader disagree on how bytes map to characters.
Re-save or export the file as UTF-8
The fix happens at the source file, not inside the analysis tool: In Excel, use File → Save As and choose CSV UTF-8 (Comma delimited) if available, rather than the plain CSV (Comma delimited) option. In Google Sheets, File → Download → Comma-separated values (.csv) exports as UTF-8 by default. In a plain text editor (e.g., Notepad++, VS Code), open the file, confirm or change the detected encoding, and use Save with Encoding → UTF-8 (without BOM, unless a downstream system specifically expects one). From a command line, a tool such as iconv -f WINDOWS-1252 -t UTF-8 input.csv > output.csv converts once the source encoding is known. Save the corrected file under a new name so the original export is preserved for comparison.
Confirm the source encoding when it is not obvious
If the source encoding is unknown, check a few signals before guessing: Open the file in a text editor that reports detected encoding. Look for a repeating pattern in the garbled characters (e.g., é almost always means UTF-8 bytes were misread as Windows-1252, while ’ almost always means a UTF-8 curly apostrophe was misread as Windows-1252). Ask which system produced the export and how; the same source system usually produces the same encoding every time. Avoid guessing by trial and error across many candidate encodings; confirm the likely source first.
Validate the result before using it
After converting, before trusting the file: Spot-check the specific values that were garbled and confirm they now render correctly. Confirm row and column counts match the original export. Check the first header cell for a stray character or invisible BOM artifact. Re-open the corrected file in more than one tool if possible, since some viewers mask encoding problems that others reveal. A file that "looks fine" in one viewer is not proof the encoding is correct; a viewer can silently substitute a replacement character without visibly breaking the layout.
What I.S.A.A.C currently does with file encoding
I.S.A.A.C reads an uploaded CSV in the browser and decodes it as UTF-8, which also strips a leading UTF-8 byte-order-mark automatically. If a CSV was saved in a different encoding (most commonly Windows-1252 from an older Excel export), expect accented letters, curly quotes, or currency symbols to render incorrectly until the source file is saved or converted as UTF-8 before upload. Do not imply that I.S.A.A.C automatically detects the source encoding or converts non-UTF-8 files unless that behavior is verified in the current production build.
Concrete examples
Example 1: Windows-1252 read as UTF-8
Original value Garbled value Cause --- --- --- Café Deluxe Café Deluxe UTF-8 bytes for é decoded one byte at a time as Windows-1252 don't ship don’t ship UTF-8 bytes for a curly apostrophe decoded as Windows-1252 Re-saving the source file as UTF-8 (not re-typing the values) resolves both.
Example 2: A stray character glued to the header
Header as exported Header as read --- --- OrderID OrderID This pattern indicates a UTF-8 byte-order-mark that was not stripped by the reading tool. Confirm whether the analysis tool strips a leading BOM before assuming the column name itself changed.
Example 3: UTF-16 file misread as UTF-8
Symptom Likely cause --- --- Nearly every character replaced with �, or the file appears mostly blank The file was exported as UTF-16 and is being decoded as UTF-8 This pattern differs from Example 1: instead of a few wrong letters, most of the visible text is affected, which points to a mismatched multi-byte encoding rather than a single-byte one.
Example 4: Mojibake that looks like real data loss
Field What it looks like What it usually is --- --- --- CustomerName René Müller Not a corrupted or duplicated record — the same name with an encoding mismatch Treating this as a data-quality or duplicate-detection problem (for example, assuming René Müller and René Müller are two different customers) can create incorrect duplicate flags. Fix the encoding first, before running any deduplication or matching logic. All examples are fictional and illustrate encoding-diagnosis methods, not customer outcomes.
Examples are illustrative and are not customer results.
Common questions
Why does my CSV show symbols like é or ’ instead of normal letters?
The file's bytes were written in one character encoding (commonly Windows-1252 from an Excel export) and are being read back in a different one (commonly UTF-8). The original data is usually intact; the display is wrong until the file is re-saved or converted to match.
Is mojibake the same as data corruption?
No. Mojibake is a decoding mismatch, not lost data. Real data loss usually shows up as blank or truncated fields and missing rows, not just wrong-looking accented characters or symbols.
How do I convert a CSV to UTF-8?
Re-save or re-export the file as UTF-8 from its source application (for example, Excel's "CSV UTF-8" save option, or a text editor's "Save with Encoding" command), rather than manually retyping the affected values.
What is a byte-order-mark (BOM), and does it cause problems?
A BOM is a few invisible bytes at the start of a UTF-8 file that mark its encoding. Most modern tools strip it automatically. Tools that do not strip it can show a stray character glued to the first header name.
Why does one CSV look garbled everywhere, while another only has a few wrong letters?
The pattern depends on the encoding mismatch involved. A single-byte encoding mismatch (such as Windows-1252 read as UTF-8) usually distorts only non-ASCII characters like accents and curly quotes. A multi-byte mismatch (such as UTF-16 read as UTF-8) usually distorts most of the visible text.
Can encoding errors cause false duplicate rows?
Yes. Two records that are actually the same value in different encodings, such as René Müller and René Müller, can be mistaken for different customers if encoding is fixed inconsistently across a dataset. Fix encoding before running duplicate checks.
Does I.S.A.A.C automatically detect and fix CSV encoding?
I.S.A.A.C reads uploaded CSVs as UTF-8 and strips a leading UTF-8 byte-order-mark automatically, but it does not automatically detect or convert other source encodings. Save or export the file as UTF-8 before uploading if characters look garbled.
Keep exploring
See what your own CSV is saying.
Try the browser workspace with a real file and keep the public guide open when you need help.
Start free