Edit a CSV in Excel without breaking IDs, dates, or encoding

You only need to fix a few rows in a product CSV and upload it again.

Double-click, edit, save. That sounds like the whole job.

Then the import fails—or worse, it succeeds and you later discover that SKU 00123 became 123, a long ID changed, or a date-like code was interpreted as a date.

The tricky part is that the worksheet may have looked completely normal.

The goal is not simply “edit the CSV in Excel.” The goal is to return the file to the target system without changing the meaning of the data.

A CSV can change at three different moments

It helps to think of the workflow in three stages:

1. when Excel reads the file
2. while you edit the worksheet
3. when Excel writes a new CSV

Leading zeros can disappear during import. Temporary helper columns can survive the edit. The final export can differ from the workbook you were looking at.

That is why the workflow does not end when you click Save. It ends after you inspect the exported CSV.

0. Keep the original file untouched

Make a working copy first.

products_original.csv
products_editing.csv

It feels trivial, but the original becomes your best diagnostic tool later.

If an ID changes, you can answer the important question immediately: was it already like that, or did the editing workflow change it?

A rollback copy is also a comparison baseline.

1. Before Excel, learn three things about the file

You do not need a full forensic analysis.

Start with:

• encoding
• delimiter
• header/schema

If the original already has mojibake or one-column parsing, fix that before editing values.

If the receiving system provides an official template, compare the headers before you start.

• CSV Encoding & Delimiter Inspector — check text and field splitting.
• CSV Header Diff — compare your file against the target template.

2. Import deliberately instead of treating a double-click as the workflow

Open Excel first and use Data → From Text/CSV.

The preview lets you stop before bad parsing becomes worksheet data.

Check:

• can you read the text?
• do fields split into the expected columns?
• are there IDs with leading zeros or very long digit strings?

If the preview is one big column, fix the delimiter first. If the columns are right but the characters are wrong, fix encoding first.

Do not start correcting cells on top of a broken import. That only makes the original failure harder to see.

3. Find the digits that are not really numbers

Look for column names such as:

sku, product_id, postal_code, member_id, tracking_number, order_id.

These may contain only digits without being values you ever want to calculate.

00123 is a five-character identifier, not just the number 123.

A 20-digit order ID is not a “very large number.” It is an identifier written with digits.

All digits does not mean numeric type.

Current Excel versions include Automatic Data Conversions controls for leading zeros, long numbers, scientific notation, and date-like patterns. Power Query can also keep selected columns as text during import.

Use the data shape to find risky columns, then use business meaning to decide how they should be treated.

4. During editing, treat the destination schema as the source of truth

For an EC platform, CRM, ad platform, or other importer, the receiving specification is the contract.

Excel may make it convenient to:

• rename headers
• add helper columns
• sort rows
• create temporary formulas

That is fine while you work.

Before export, bring the file back to what the importer expects.

Watch for:

• required headers changed or missing
• helper columns left behind
• blank vs 0 vs false being treated as the same thing
• duplicate removal based on the wrong key
• date formats changed from the target specification

Deduplication is a good example: the hard part is not clicking “remove duplicates.” The hard part is deciding what makes two rows the same record.

5. Keep the working workbook separate from the delivery CSV

If you use formulas, colors, multiple sheets, or helper columns, keep the working file as .xlsx.

Then export a separate CSV for the target system.

products_original.csv
products_working.xlsx
products_ready_for_import.csv

The filenames tell you which stage each file represents.

CSV will not preserve workbook features such as multiple sheets, formatting, and workbook-level behavior. That is fine—the CSV is the delivery artifact, not the workspace.

6. Inspect the exported CSV, not the worksheet you were looking at

This is the step people skip.

You finish editing. The sheet looks correct. You export the CSV.

But the next system receives products_ready_for_import.csv, not the Excel screen.

Run checks against that new file:

• Excel CSV Damage Checker — look for leading-zero loss, long-number changes, dates, and scientific notation.
• CSV Header Diff — confirm the headers still match the target.
• CSV Key Uniqueness Checker — verify keys that must be unique.
• CSV Missing Value Analyzer — check required columns for new gaps.

Then compare a few representative values against the original, especially:

• leading-zero IDs
• 16+ digit IDs
• E-like codes
• ambiguous dates
• descriptions containing commas or line breaks

That is the round-trip check: did the file come back out with the same meaning it had when it went in?

Example: editing a product CSV

Suppose the file contains:

sku = 00123
product_id = 123456789012345678
release_date = 03/04/2026
description = Large, red mug

Every field deserves a little attention.

• sku has a leading zero.
• product_id is longer than Excel’s numeric precision.
• release_date is ambiguous without a date convention.
• description contains a comma.

A safe workflow is:

1. Keep the original.
2. Confirm encoding and delimiter.
3. Import through Excel’s text/CSV flow.
4. Keep sku and product_id as identifiers/text.
5. Confirm the date convention before converting release_date.
6. Edit the description normally and let proper CSV export handle quoting.
7. Save your working workbook separately.
8. Export a new CSV.
9. Inspect that new CSV before uploading it.

None of the individual steps is difficult. The safety comes from the order of the checks.

Final seven-point check

• The untouched original still exists.
• Encoding and delimiter are known.
• Required headers are unchanged.
• IDs and SKUs were protected as identifiers, not numbers.
• Ambiguous dates were not guessed.
• The working workbook and delivery CSV are separate files.
• The exported CSV itself was checked.

A simple mental model is enough:

check before opening → import deliberately → protect meaning while editing → inspect the exported file.