Fix CSV encoding for a large dataset handoff

You open a large CSV and names or symbols look like gibberish. Or the file looks fine on your computer but arrives garbled for the person receiving it. The cause is often a mismatch between the file's encoding and the way the reader interprets its text.

Check a copy before changing anything. The CSV Editor can open large CSV files, up to 10 million rows, so you can inspect the text and confirm that the data still lines up in columns.

Check the CSV before changing it

1. Make a separate copy of the original CSV. Keep the untouched file as a backup, especially if it is the only copy or came from a system you cannot export again.
2. Open the copy in the CSV Editor. Check several rows with accented letters, curly quotes, currency symbols, or characters from other writing systems.
3. Look for text that seems corrupted, such as café where you expected café. Also check that commas inside quoted fields have not shifted information into extra columns.
4. Compare a few values with the original system or a known-good copy. Check the same rows in the app or workflow that will receive the handoff, because it may interpret the file differently.

Do not overwrite the original after an inspection. A file can look garbled because the reader chose the wrong encoding, even though the original bytes still contain the correct text.

What the result means

Text looks right in the CSV Editor and in the receiving workflow

The file is probably readable as-is. Before sending it, check a few more rows from different parts of the dataset. A correct preview does not prove that every field is complete, but it is a useful first check.

Text shows patterns like é or ’

This is often called mojibake: text bytes were read using the wrong character encoding. For example, UTF-8 text may have been interpreted as a Western legacy encoding. Reopen the untouched original using its actual encoding, then save a new copy as UTF-8. Do not convert the already garbled copy unless you know it still contains the original text correctly.

Some characters appear as � or as question marks

The original text may already have been damaged during an earlier import or save. Ask the sender to export the data again from its source. If the source still has the correct names and symbols, a fresh export is safer than trying to repair the damaged version.

The characters look right, but the columns do not

That is usually a delimiter or quoting problem, not an encoding problem. A delimiter separates fields, and quotes allow a field to contain a comma. Ask the recipient which delimiter and quoting rules its importer expects, then check those separately from the text encoding.

How to fix the encoding

1. Ask for a fresh export in UTF-8. If the source system can still display the text correctly, request a new CSV saved as UTF-8. This avoids trying to recover text from a copy that may already have been changed.
2. Match the encoding at import. If the CSV looks wrong only in the receiving app, use that app's text or encoding import option and select UTF-8. If the sender used an older system, ask which encoding it exported, then select that encoding when reading the original file.
3. Convert only from a known source encoding. If a fresh export is not available, use a text conversion method that can read the original encoding and write UTF-8. Work on a copy, and avoid guessing: a wrong source choice can turn correct text into permanent corruption.
4. Check whether the receiver needs a UTF-8 signature. Some older import workflows recognize UTF-8 more reliably when the file includes a byte order mark, sometimes called a BOM. Use that format only if the recipient asks for it or confirms that its importer needs it.
5. Validate the new file before sending it. Reopen the converted copy and inspect representative rows, including non-English characters and punctuation. Compare row counts and important identifiers with the source, and confirm that quoted commas and column positions remain correct.

For a very large file, choose a conversion method that handles the file without loading the entire dataset into memory. Keep the source untouched, and do not rely on a quick preview of the first few rows alone.

Protect the rest of the dataset during conversion

Encoding is only one part of a safe handoff. Opening and resaving a CSV in a general-purpose spreadsheet can change values that look like dates or numbers. Product IDs such as 00127 may lose their leading zeros, and long digit strings may be reformatted. Preserve identifiers as text when the destination expects exact values.

Also confirm the recipient's expected delimiter, line endings, header row, and quoting rules. Test the new file with a small representative sample if the receiving system allows it. A useful sample includes ordinary text, accented names, non-English characters, commas inside quoted fields, and leading-zero IDs.

The CSV Editor is useful for checking and editing rows, but do not assume that opening a file there changes its character encoding. Use it to inspect the result after a conversion, and keep a separate backup of each version. Files you open in TooLab tools stay on your device.

If you need to identify the file's current text encoding before import, see how to check a CSV file's encoding.