CSV encoding errors in an ecommerce sync

A product sync can turn names like “Café” into “Café,” replace accented letters with question marks, or reject a CSV before importing it. These symptoms often point to an encoding mismatch: the file’s bytes are being interpreted using the wrong character set.

Here’s how to check the file, tell encoding problems apart from other CSV issues, and choose a repair that doesn’t damage product data. The CSV Editor can help you inspect a file in your browser before you try another import.

Check the CSV before changing it

1. Make a copy of the original export and open the copy in the CSV Editor. Inspect a few product names, descriptions, and other fields that contain accented letters or symbols. The editor can open large CSV files, up to 10 million rows.
2. Compare suspicious text with a trusted source, such as the product page in your store or the original product catalog. Look for patterns like Français instead of Français, a black diamond with a question mark, or question marks in place of characters.
3. Check the same records in the CSV’s source, if you can. If the source is correct but the CSV is wrong, the export step may have used the wrong encoding. If the CSV looks correct but the store displays broken text, the import settings may be the problem.
4. Check a simple field such as a number or product code as well. If columns have shifted, or commas inside descriptions split one value into several columns, you may have a delimiter or quoting problem instead of an encoding problem.

For a broader explanation of how to inspect a CSV’s character encoding, see how to check a CSV file’s encoding before import.

What the result means

Text looks correct in the CSV but breaks in the store

The export may be fine, while the ecommerce importer reads it using a different encoding. Check the store’s import options for a character set or encoding choice. If the file is UTF-8, select UTF-8 rather than a legacy option such as Windows-1252. If the importer offers no choice, check its CSV requirements or test a small copy first.

Text is already broken in the CSV

The problem happened before the import. The export application may have decoded the source incorrectly or saved it in an encoding the next tool does not recognize. If possible, export a fresh file from the original product data and choose UTF-8. Changing the importer cannot restore text that is already damaged in the file.

You see question marks or replacement symbols

Some characters may have been lost when the file was saved. A question mark or the replacement character � can mean the original character was replaced, not merely displayed incorrectly. Use a clean source or re-export the data rather than replacing every question mark by hand.

The first column header has an unexpected mark

A UTF-8 byte order mark, often called a BOM, can help some programs recognize a UTF-8 file. Other importers may treat it as part of the first column name, so a header such as Product name may not match the store’s expected field. Test the importer’s UTF-8 options before removing the BOM, since some software relies on it.

How to fix the encoding problem

1. Keep the original untouched. Work from a duplicate of the export. This gives you a way back if a conversion changes product descriptions, symbols, or identifiers.
2. Find out what the importer expects. Check the store’s CSV instructions or import options for a required encoding. UTF-8 is a common choice for ecommerce catalogs because it supports characters from many languages, but follow the importer’s requirements.
3. Export a fresh UTF-8 file when the source is available. In the source application, choose an option labeled CSV UTF-8 or a similar UTF-8 export. If the store offers an encoding selector during import, choose the same encoding used by the file.
4. Test a small batch first. Import a copy with a few products that include the affected characters. Confirm names, descriptions, and headers in the store before running the full sync. A test catches importer settings that handle UTF-8 or a BOM differently than expected.
5. Rebuild text that is already corrupted. If the CSV itself contains Café or Caf?, changing its encoding label or saving it again as UTF-8 may preserve the wrong characters. Re-export from a clean source, or replace only the affected values using verified product data.
6. Check the other CSV settings separately. Confirm the delimiter, quote character, header row, and column order against the store’s requirements. Encoding changes how bytes become text; it does not fix commas, missing columns, or mismatched field names.

Use the CSV Editor to find and review affected values, but don’t assume that editing visible text can identify the file’s original encoding. A browser editor can show you what the file currently decodes to; it cannot reliably infer which characters were intended after information has been lost.

Why “save as UTF-8” does not always repair it

Encoding describes how characters are represented as bytes. If a UTF-8 file is read as Windows-1252, the bytes for an accented letter can display as several unrelated characters. Saving that incorrect display as UTF-8 may simply encode the mojibake, the garbled text, into a new UTF-8 file. The new file is technically UTF-8, but the product name is still wrong.

A clean re-export is the safest repair when the source data is correct. If you only have the damaged CSV, compare each affected value with a reliable source before correcting it. Avoid broad find-and-replace changes: characters such as apostrophes, trademark symbols, and non-English letters may be valid in some products but not others.

Keep a clean copy for the next sync

Once the test import looks right, save the corrected file separately and keep the original export until the full sync is confirmed. The CSV Editor runs in your browser, and files you open stay on your device.