CSV Guide

What a CSV repair tool can safely fix

The most useful CSV repair tool is not the one that changes the most data. It is the one that knows when to stop.

Structural repair and business-data repair are different

A parser can prove facts about CSV syntax: where fields begin and end, whether rows have consistent widths, whether the bytes are valid UTF-8, and whether a delimiter can be normalized. It cannot prove what a missing SKU, price, product relationship, or date was supposed to be.

Usually safe when the source is unambiguous

  • Re-serializing parsed fields with a chosen delimiter.
  • Writing confirmed decoded text as UTF-8.
  • Normalizing line endings.
  • Removing a purely empty trailing record.
  • Trimming header whitespace when the user explicitly requests it.
  • Adding correct CSV quoting during re-serialization.

Needs confirmation

  • Removing duplicate records.
  • Changing a legacy source encoding.
  • Changing a header name to match a destination schema.
  • Removing BOM bytes when a destination is known to reject them.
  • Repairing a quote when more than one interpretation is possible.

Should not be guessed automatically

  • Creating missing SKUs or handles.
  • Inventing prices or inventory values.
  • Changing dates because they “look wrong.”
  • Moving values between columns when the intended field is uncertain.
  • Creating product or variant relationships.
  • Replacing unknown garbled text with guessed words.

Why “Fix All” can be dangerous

A button can create false confidence. If a repair tool rewrites ambiguous data silently, the resulting CSV may import successfully while carrying incorrect values. A failed import is visible; silently incorrect imported data can be much harder to detect.

CSVFixLab’s repair rule

The current MVP enables a repair download only when the parser can safely re-serialize the data under the selected rules. Broken or unclosed quotes, inconsistent row widths, duplicate headers, empty headers, or an unconfirmed non-UTF-8 source block automatic repair.

Always review before production

A structurally valid file is not a guarantee that the destination will accept it. Platform-specific rules, account state, duplicates, references, limits, and business constraints can still fail. Keep the original file and test repaired output in a controlled import first.