Why Saving Your CSV in Excel Changes It, and How to Keep the Original Safe (2026 Guide)

Diagnose it in 30 seconds: compare the file before and after the save

The first thing to establish when a CSV file looks different after Excel touched it is whether the file itself changed, or only the Excel view of it, because the two cases have very different fixes. Here is the 30-second test. Before you open a CSV in Excel, make a copy of it. After you save from Excel, open both files in a plain text editor, Notepad on Windows or TextEdit in plain-text mode on a Mac, and compare them side by side. If the saved copy shows different delimiters, different characters, stripped zeros, or reformatted dates, the file changed. If the two files match character for character, only the Excel display was misleading you, and the file is safe.

The second clue is where the changes sit. A save that rewrote the file changes values across the whole file in a consistent pattern: every comma delimiter became a semicolon, every accented name turned into question marks or odd letter pairs, every code lost its leading zeros. Random damage in one row only, or a single missing row, points to something else, like an editing mistake or a truncated export. Consistent, file-wide changes are the signature of a save rewriting the file under Excel defaults, and they tell you exactly which setting to fix: the delimiter setting, the encoding choice, or the way the file was opened in the first place.

The third check decides whether rescue is still possible, and it is the one people skip. If you still have the pre-Excel copy, or the source the CSV came from, nothing is lost: regenerate or re-import from the good copy and the problem is over. If the saved file overwrote the only copy, rescue depends on backups, version history, or re-exporting from the source system, which the rescue section covers. Until you have checked, do not save again, do not close the workbook over the same file, and do not delete the saved copy: a damaged copy that still holds most of the data is better evidence than no copy at all.

BEFORE (as exported, comma delimited, UTF-8):
code,zip,name,shipDate,note
00123,02138,Zoë Café,2026-03-04,fragile; handle with care
00456,07477,Müller,2026-04-03,gift

AFTER (saved from Excel on a European-locale machine):
code;zip;name;shipDate;note
123;2138;Zoë Café;03.04.2026;fragile; handle with care
456;7477;Müller;03.04.2026;gift

What changed: commas became semicolons, leading zeros vanished,
dates were reformatted, and one note split into two columns.

Notice what this example proves: no single setting caused all of it. The delimiter changed because of the machine locale, the zeros vanished because of type guessing at open time, and the dates changed because Excel stored them as dates and wrote them back in its own display format. A save does not introduce one error. It locks in every guess Excel made when it opened the file, all at once, and that is why the save feels so destructive even though each individual guess seemed harmless on screen.

Why a save is not a copy: what Excel actually writes to disk

To understand why saving changes a CSV, you need one fact about what Excel does when it opens the file. Excel does not hold the file as text. It parses the text into cells, decides a type for each cell, applies your regional settings, and shows you a grid. What you see is Excel interpretation of the file, not the file itself. When you save, Excel writes the grid back out as text. So the saved file reflects the grid, with all of its guesses baked in, not the original characters. The round trip from text to grid and back to text is where every change in this guide happens.

The first thing the write-back drops is everything that is not a cell value. A CSV file holds rows and columns of values and nothing else, so when Excel saves one, it keeps only the text and values as displayed in the cells of the active worksheet. Charts, images, cell colors, bold text, merged cells, data validation rules, and hyperlinks do not survive, because the format has nowhere to put them. Formulas are replaced by whatever they currently evaluate to, so a cell holding a formula that computes a total saves as the total number, not the formula. That is usually what you want when exporting for another system, but it means the saved CSV is a snapshot of one moment, not a working spreadsheet, and reopening it will never bring the formulas back.

The second thing the write-back drops is every sheet except the one you were looking at. A workbook can hold many sheets, but a CSV file is a single table, so Excel saves only the active worksheet and warns you that the other sheets will not be saved. People click through that warning every day, and the saved file then holds one sheet worth of data while the rest stays behind in the unsaved workbook. If you close the workbook without saving it in spreadsheet format, the other sheets are gone. The warning is Excel telling you, plainly, that the save is lossy, and the safe response is to keep the workbook saved separately in its own format before you export anything to CSV.

The third thing the write-back changes is the values themselves, because Excel saves values as displayed, not as stored. A cell storing a precise number that you formatted to two decimals saves as the two-decimal display, not the full stored value. A date stored as a serial number saves in the display format of your machine. A code that Excel guessed was a number saves as that number, without its leading zeros. None of this is a bug. It is what saving a grid as text means. But it means the saved file can differ from the original in ways that are invisible until another program reads it, which is why checking the saved file in a text editor matters more than checking it on screen.

The silent overwrite: how Ctrl+S turns a guess into the file

The most damaging save is not Save As. It is the plain Ctrl+S, or the close-and-save prompt, on a CSV file you only meant to look at. You double-click a CSV to check a value, you fix one typo, you press Ctrl+S out of habit, and Excel rewrites the entire file under its own defaults. You changed one cell. Excel rewrote every row. That asymmetry is the heart of this problem: a save is a whole-file operation, not a patch to the cell you touched, and every guess Excel made at open time becomes permanent in the same keystroke.

Excel does warn you, twice, and both warnings are easy to dismiss. The first warning says the file may contain features that are not compatible with CSV, which is Excel telling you formatting and extra sheets will be lost. The second, on some versions, asks whether to keep the current format. People who see these dialogs every day click Keep Current Format without reading, because the dialog looks like a routine confirmation rather than a data-loss warning. It is worth slowing down for exactly these two dialogs. They are the last moment when the original file still exists untouched, and choosing not to save, or choosing Save As with a new name, costs nothing and preserves everything.

The round trip is what makes the overwrite so hard to undo. Opening the file guesses the types, and saving writes the guesses back, so the second open starts from already-guessed values and guesses again on top of them. A code that lost its zeros on the first open cannot regain them on the second, because the zeros are no longer in the file for any program to read. A date that swapped day and month on the first open swaps again or stays swapped, because the file now holds the swapped date as if it were the truth. Each round trip through Excel can only lose information, never restore it, which is why the rule in this guide is absolute: never let Excel save over the only copy of a CSV file.

Change 1: the delimiter swap, when commas become semicolons

The most visible save change is the delimiter swap: a comma-delimited file comes back semicolon-delimited, and the next program that reads it either puts every row in one column or rejects the file. The cause is your machine list separator, a regional setting that Excel uses whenever it writes a CSV file. In North America and the United Kingdom, the list separator is a comma, so a saved CSV stays comma-delimited. In much of Europe, the comma is the decimal symbol, so the list separator is a semicolon, and Excel writes semicolons instead of commas. The file extension stays .csv either way, so nothing in the filename warns the next reader that the delimiter changed.

This is the same delimiter problem covered in the companion guide on the one-column problem, but the save direction deserves its own warning, because the fix is different. When a file opens in one column, you fix the opening. When a file saves with the wrong delimiter, you fix the export: in Excel, go to File, then Options, then Advanced, uncheck Use system separators, and set the decimal separator to a period and the thousands separator to a comma, which makes Excel use a comma as the list separator. Change it back after exporting if you only need it for one file, because the setting affects every CSV Excel writes while it is changed. On a Mac, the same setting lives in System Settings, under Language and Region, in the number separators.

There is also a simpler check that catches this change before it causes damage. Open the saved file in a text editor and look at the first line. If the header shows semicolons where the original showed commas, the delimiter swapped, and you should re-export with the setting above instead of sending the file. A text editor shows you the truth in one glance, while Excel hides it completely, because Excel reads both delimiters into the same grid. Never judge a saved CSV by how it looks in Excel. Judge it by how it looks as text.

Change 2: the encoding downgrade, when accented letters break

The second save change is quieter and nastier: the encoding downgrade. Excel offers two CSV save types that look almost identical, and picking the wrong one corrupts every non-English character in the file. CSV UTF-8 writes the file in UTF-8, which covers accented letters, umlauts, and non-Latin scripts. Plain CSV writes the file in your system legacy encoding, which on many Windows machines cannot represent those characters at all, so they come back as question marks or wrong letters. The two options sit next to each other in the Save As list, and the plain one is the one people pick out of habit.

The rule is simple: always choose CSV UTF-8 when saving from Excel, unless the receiving program explicitly demands the legacy format. And even then, check the result in a text editor, because the legacy encoding is a one-way loss: once an accented character has been replaced by a question mark in the saved file, no re-import can recover the original letter, because the saved file no longer holds it. The companion encoding guide covers the full diagnosis, including the byte-order mark trick that makes Excel guess UTF-8 on double-click, but the save rule stands on its own: the encoding you pick at save time is the encoding the next reader gets, and the wrong pick damages every non-ASCII value at once.

One more encoding detail matters for files from this page. The converter download is plain UTF-8 with no byte-order mark, which is the cleanest form for most tools, but it means Excel double-click may misread accented letters on some Windows machines. That is an opening problem, covered in the encoding guide, not a save problem, and it does not change the save rule. Whatever the source encoding, save from Excel as CSV UTF-8, and verify in a text editor that accented names still read correctly before you send the file on.

Change 3: the type rewrite, when guesses become the data

The third save change is the type rewrite, and it is really three companion problems arriving together, because the same open-then-save round trip writes back every guess Excel made. Leading zeros disappear, because Excel read the codes as numbers at open time and writes numbers back without them. Dates get reformatted or swapped, because Excel stored them as serial numbers and writes them back in its own display format. Long IDs lose their tail digits, because Excel keeps only fifteen significant digits and writes zeros for the rest. Each of these has its own companion guide with its own fixes, and this post does not repeat those fixes, because the save lesson is the same for all three: the damage happened at open time, and the save is what made it permanent.

What is worth stating here is the test that separates a display problem from a saved problem. Open the file in a text editor. If the codes, dates, and IDs read correctly there, the file is still good and only the Excel view is wrong: close without saving and re-import properly. If the text editor shows stripped zeros, swapped dates, or truncated IDs, the save already rewrote the file, and the rescue section is your only route. That test takes ten seconds, and it is the single most useful habit in this whole guide, because it tells you whether you still have a good file or only a damaged one.

It is also worth knowing what does not get rewritten. Plain words, short numbers that need no guessing, and values Excel left as text all survive a save unchanged, which is why a saved file can look mostly right while being wrong in exactly the columns that matter: codes, dates, and IDs. Spot-checking one ordinary row proves nothing. Check the sensitive columns specifically: the code column, the date column, and the long-ID column, in a text editor, after every save, before you send the file anywhere.

Four fixes that do not work after a bad save

Before the fixes that work, it is worth clearing away the four fixes that do not, because each one wastes time and one of them makes things worse. The first is reformatting the saved file after the fact. Changing a column format changes how stored values display, but it cannot restore characters the save already removed. A code saved as 123 cannot regain its zeros by formatting the column as Text, because the file now holds 123 and nothing else. Formatting is display. The saved text is the data, and display changes never touch it.

The second is pressing Undo after saving. Undo reverses edits inside the open workbook, but it does not unwrite a file that was already saved to disk. Once the save completes, the disk holds the rewritten file, and no amount of undoing in the workbook brings the original characters back. The third is quoting the values in the saved file. Quotes control how commas inside a value are handled, not how Excel types a value, and Excel strips quotes on import and guesses the type anyway, so adding quotes to a damaged file changes nothing about the damage. The fourth is find-and-replace across the saved file to repair swapped dates or stripped zeros by hand. That works only if every row suffered the same change, which is never the case for mixed columns, so a blanket replacement corrupts the rows that were right while fixing the rows that were wrong.

Knowing which fixes fail saves you from the most common trap of all: believing the problem is solved because the workbook on screen looks right, while the file on disk is still wrong. The screen is not the file. The text editor is the file. Every repair in the rest of this guide starts from that distinction, and every check ends with it.

Fix 1: never save over the original, keep a master copy

This is the fix to try first, because it costs nothing, changes nothing about your system, and it makes every other mistake in this guide recoverable. Keep the original CSV file untouched, and do all of your Excel work on a copy. The workflow is deliberately boring: when a CSV arrives, save it to a folder called originals and never open that copy in Excel. Copy it to a working folder, and open the working copy. If a save goes wrong, delete the working copy, copy the original again, and start over. No rescue, no repair, no lost data, because the good file was never at risk.

If you produce the CSV yourself, keep the master in spreadsheet format and treat the CSV as an export, not the document. Work in the workbook, save the workbook, and export a fresh CSV whenever you need one, with a versioned name like customers-2026-11-05.csv so an export never silently replaces an earlier one. A CSV is a flattened snapshot, not the data itself, so the master workbook, or better still the database or JSON the data came from, is the thing to protect. The moment a CSV becomes the only copy of your data, every Excel save becomes a risk to the only copy, and that is the situation this guide exists to prevent.

• ▸Save every incoming CSV to an originals folder before opening it anywhere.
• ▸Work only on a copy, and name exports with a date so they never overwrite silently.
• ▸Keep the master workbook saved in spreadsheet format, separate from any CSV export.
• ▸If a save goes wrong, throw away the working copy and start again from the original.

This rule also protects you from the multi-sheet warning. If your workbook holds several sheets and you export one to CSV, the workbook itself stays intact in its own format, and you can export each sheet separately whenever you need it. The CSV export is a one-way snapshot for a specific purpose, and the workbook remains the living document. People lose sheets not because CSV is dangerous, but because they closed the workbook without saving it after exporting, and the master-copy habit makes that mistake impossible.

Fix 2: edit safely, in a text editor or through a proper import

The second fix is about how you edit, and it has two branches depending on the size of the job. For a small edit, changing a value or two, fixing a typo, correcting one row, do not open the file in Excel at all. Open it in a text editor, make the change, and save from the editor. A text editor writes back exactly the characters you see, with no type guessing, no delimiter swap, and no encoding change, as long as you keep the same encoding when you save. For a one-row fix, the text editor is not a workaround. It is the correct tool, and it is faster than Excel for the job.

For a big edit, where you need sorting, filtering, or formulas, import the file properly instead of double-clicking it. Open a blank workbook, go to Data, then From Text/CSV, and in the preview set the delimiter, the encoding, and the type of every sensitive column before loading: codes and IDs to Text, dates to Text or to Date with the source locale. Do your work, then export with Save As, choose CSV UTF-8, give the export a new name so it cannot overwrite the original, and check the result in a text editor before you send it. The import step is where you take control of all three guesses at once, and the text-editor check is where you prove the export is clean.

One more safe-editing option deserves a mention: edit the data at its source instead of editing the CSV. If the CSV came from JSON, fix the JSON and convert again, which produces a clean file with no round-trip damage at all. If it came from a database, re-export from the database. Re-generating from source is always cleaner than repairing a file that has already passed through a spreadsheet, because the source holds the true values and the export holds only a snapshot of them.

Fix 3: verify before you send, the two-minute text-editor check

The third fix is a habit, not a setting: check every saved CSV in a text editor before you send it anywhere, using a short checklist that takes about two minutes. Open the saved file and the original side by side, and check five things. First, the delimiter: does the header line use the same separator in both files. Second, the row count: does the saved file hold the same number of lines, remembering that values containing line breaks can span lines. Third, the sensitive columns: do codes still carry their leading zeros, do dates still read the way the source wrote them, do long IDs still hold all their digits. Fourth, the encoding: do accented names still read correctly, with no question marks or odd letter pairs. Fifth, the quoting: are values that contain the delimiter still wrapped in quotes, so they stay in one column.

If any check fails, do not send the file and do not try to patch it in the spreadsheet. Go back to the original, fix the setting that caused the failure, and export again. A failed check is cheap when the original still exists and expensive when it does not, which is why this check belongs before sending, not after someone complains. The most common reaction to a failed check is to open the saved file in Excel again to fix it, which starts another round trip and usually adds new damage. Fix the export, not the exported file.

Make the check part of the export itself, not a separate chore. Save As, open in a text editor, run the five checks, then send. After a few exports the check becomes automatic, and the files you send stop coming back with complaints about missing zeros, swapped dates, or single-column layouts. The check is also your evidence: if a recipient reports a problem later, you can compare the file you sent against the original and show exactly where the change happened, instead of guessing.

Rescue a file that was already saved over

Sometimes the advice arrives too late, and the saved file already overwrote the only copy. Rescue is possible in some cases, and the honest answer is that it depends on what else exists besides the damaged file. First, check for automatic backups: OneDrive and SharePoint keep version history for files stored in them, so right-click the file and look for previous versions before you do anything else. Windows File History and Mac Time Machine keep their own copies if they were enabled. Email attachments, chat uploads, and shared drives often hold an earlier copy of the same file, sent before the bad save, and that copy is frequently the cleanest rescue available.

Second, if no earlier copy exists, check whether the damage is uniform enough to reverse. If every date swapped under one convention and every original day was 12 or less, a formula can swap them back, and if every code lost the same number of zeros, those zeros can be restored by formatting, but only when the loss was uniform across the whole column. Work on a copy, never on the only version, and check the result against a known record before trusting it. If the damage is mixed, some rows swapped, some stayed text, some codes became dates, the original characters are gone from that copy in a way no formula can untangle, because a saved number does not record what it used to be.

Third, and most reliably, regenerate the file from its source. Re-export it from the database, the tool, or the JSON it came from, and this time open it with a proper import and never save over it. If the source is JSON, the converter on this page produces a fresh CSV from the original JSON in seconds, with every value exactly as written, and that fresh file replaces the damaged one entirely. Whatever route you take, keep the damaged copy aside until the replacement checks out in a text editor. Deleting the only copy before verifying the replacement is how a recoverable problem becomes a lost dataset.

What this means for files from this page converter

The converter on this page produces exactly the kind of file this guide is about, so it is worth stating its behavior plainly, verified against the real code rather than assumed. The conversion engine was run on a two-row sample holding the codes 00123 and 00456, the ZIP codes 02138 and 07477, the 18-digit IDs 123456789012345678 and 987654321098765432, the dates 2026-03-04 and 2026-04-03, the accented names Zoë Café and Müller, and the notes fragile; handle with care and gift. With comma delimiters, it produced every value byte-identically, with the comma-containing name quoted and nothing else quoted. With semicolon delimiters, it quoted exactly the semicolon-containing note and nothing else. So if your converted file shows changed values after Excel touched it, the conversion did not damage anything. The file was correct, and Excel guessed at open time and wrote its guesses back at save time.

Comma delimited (verified, real converter output):
code,zip,id,shipDate,name,note,price
00123,02138,123456789012345678,2026-03-04,"Zoë, Café",fragile; handle with care,19.99
00456,07477,987654321098765432,2026-04-03,Müller,gift,5

Semicolon delimited (verified, same sample):
code;zip;id;shipDate;name;note;price
00123;02138;123456789012345678;2026-03-04;Zoë, Café;"fragile; handle with care";19.99
00456;07477;987654321098765432;2026-04-03;Müller;gift;5

Codes, ZIPs, long IDs, and dates all survive byte-identically.
Quoting follows the delimiter: only values holding the delimiter
are quoted, in both cases.

That gives you two clean options for converted files. The first is the safe-edit route: if you need to change a converted file, change the JSON and convert again, which produces a fresh file with no round-trip damage, instead of editing the CSV in Excel and saving over it. The second is the import route: open the downloaded file with Data, then From Text/CSV, set code and ID columns to Text and date columns to Text or to Date with the source locale, do your work, and export with Save As under a new name in CSV UTF-8, checking the result in a text editor. Do not paste converted output through a spreadsheet and save it back over the download, because that round trip can introduce exactly the delimiter, encoding, and type mismatches this guide and its companions exist to prevent. Fix the opening, or regenerate from source, never the saved file.

One more converter detail matters here. The converter lets you choose the delimiter before downloading, and that choice is independent of everything Excel does afterwards. A file can carry the right delimiter and still come back with swapped dates, or the right dates and the wrong delimiter, or both wrong at once, because the delimiter you chose at conversion time is not the delimiter Excel writes at save time. If your converted file opens in one column and its values look wrong, fix both in the same import: pick the delimiter you chose at conversion time, and set the sensitive columns explicitly. The companion guide on the one-column problem covers the delimiter half in detail, the encoding guide covers the character half, and the leading-zeros guide covers the number half, and all three are linked in the related guides below.

Prevention checklist: export CSVs so nobody has to fix them

Type guessing and save rewrites are mismatches between writer and reader, so prevention means making the writer declare what the values are, in a way the reader will honor, and making the reader check before trusting. Run through this checklist when you produce or receive a CSV, and the next person who touches it will not need this guide. First, keep the source data. A CSV is a flattened snapshot, not the data itself, so if a save goes wrong, the source lets you export again cleanly instead of repairing a damaged copy. Second, never save over an original. Keep an originals folder, work on copies, and name exports with a date so nothing overwrites silently.

Third, when you export from Excel, choose CSV UTF-8, check the list separator setting before saving, and verify the export in a text editor before sending it. Fourth, when you receive a file, open it in a text editor first if anything looks off, and confirm the delimiter, the encoding, and the sensitive columns before you let any spreadsheet save over it. Fifth, tell recipients how to open the file: a one-line note saying import with code columns set to Text and dates set to Text or to Date with the source locale prevents the whole class of problems, and it costs nothing to include with the file. Most CSV horror stories end with someone discovering too late that the damaged file was the only copy. Do not let that be your file.

Related guides

• Why Your CSV Opens in One Column in Excel, and How to Fix It (2026 Guide) →
• Why Your CSV Shows Weird Characters in Excel, and How to Fix the Encoding (2026 Guide) →
• Why Excel Drops the Leading Zeros From Your CSV Codes, and How to Keep Them (2026 Guide) →
• Why Excel Won't Open Your Big CSV File, and What to Do Instead (2026 Guide) →

Frequently asked questions