Why Excel Changes Your CSV Dates, and How to Keep Them (2026 Guide)

Diagnose it in 30 seconds: the file is fine, Excel guessed wrong

The first thing to establish when your dates change is whether the data is damaged or only misread, because the two cases have very different fixes, and the wrong fix can turn a display problem into real data loss. Here is the 30-second test. Open the same file in a plain text editor, Notepad on Windows or TextEdit in plain-text mode on a Mac. If the dates show exactly as the source wrote them there, 03/04/2026, 2026-03-04, 1-2, your data is intact and only Excel reading is wrong. The file on disk holds the right characters, and Excel changed their meaning when it opened the file. That is the common case, and every fix in this guide starts from it.

The second clue is which values changed. If ordinary words, short numbers, and punctuation look fine, but dates moved, swapped, or reformatted, and short codes like 1-2 or MARCH1 turned into dates, you are looking at type guessing, not a delimiter problem and not corruption. A delimiter problem puts whole rows in one column. Corruption scrambles everything or drops rows. Type guessing is surgical: it changes exactly the values that look like dates, and leaves everything else untouched. If 03/04/2026 became April 3 on a machine that should read March 4, and a code like 1-2 became January 2, Excel treated text as dates, and that tells you both the cause and the fix.

The third check decides whether rescue is still possible, and it uses the formula bar, not the cell. Click a changed date cell and read the formula bar. If the formula bar shows a serial number like 46085, or a date in a different arrangement than the file, the cell now holds an Excel date value, not your characters. If the formula bar shows the original characters, only the display format changed, and reformatting the cell fixes it. Until you have checked, keep the original file untouched, work on a copy, and never save a converted file back over the good one.

Why Excel guesses: a CSV file carries no types

To understand why this keeps happening, you need one fact about the CSV format: a CSV file is plain text with no header that says which values are dates, which are numbers, and which are text. A spreadsheet file carries its cell types with it. A CSV file carries neither types nor formatting. It is just characters, commas, and line breaks. When a program opens it, the program must decide what each value means, and different programs decide differently. Python csv module and Google Sheets keep CSV values as text unless told otherwise, which is why the same file looks correct in them. Excel, when you double-click a CSV file, guesses: anything that looks like a date becomes a date, anything that looks like a number becomes a number, and it does not check whether that guess was right.

That guess is the whole problem for dates, because date notation is not universal. The United States writes month first, 03/04/2026 for March 4. Most of Europe writes day first, 03/04/2026 for April 3. ISO 8601 writes year first, 2026-03-04, which is unambiguous, but most exported files do not use it. A CSV file does not say which convention its dates follow, so Excel falls back on the convention of the machine opening it. Open the same file in New York and in Berlin and you get two different spreadsheets from one file, and neither machine warns you that a choice was made. The same logic explains the second casualty: values that are not dates at all, like the range 1-2, the ratio 5/6, or the code MARCH1, match a date pattern closely enough that Excel converts them too. The file did not change. The reader changed the meaning of the characters.

It also explains why this problem appears so often with files converted from JSON. JSON does distinguish types: the string "2026-03-04" and the string "03/04/2026" are different strings, and a JSON to CSV conversion writes each out exactly as written. The conversion is correct. The opening is mismatched. The converter on this page, for example, was run on a sample holding the dates 2026-03-04, 03/04/2026, and 2026-03-04T10:30:00Z, and it produced every value byte-identically in the CSV, with no reformatting and no digits changed. Knowing that the mismatch sits at the opening step, not the conversion step, tells you where to fix it: at the import, before Excel guesses, as the next sections show.

Three ways the guess changes dates, and how to tell them apart

Type guessing changes dates in three distinct ways, and telling them apart matters because only some of them are repairable. The first is the day-month swap: 03/04/2026 becomes April 3 instead of March 4, or the reverse, silently. Nothing looks broken. The column is full of plausible dates, every one of them valid, and a quarter of your dates are wrong in a way no error message will ever flag. The swap only happens where the day is 12 or less, because only then can the day pass as a month. That is what makes it dangerous: the rows that cannot swap betray the problem, while the rows that did swap hide it.

The second way is the mixed column, and it is the giveaway that a swap happened. When a US-format file is opened on a day-first machine, rows with day 13 or higher cannot be months, so Excel leaves those cells as text while converting the rest to dates. One column then holds two kinds of cells: real dates for the first twelve days of each month, and text for the rest. Sorting that column puts the text rows at one end, filtering by date misses them, and any chart or calculation built on the column quietly drops them. If your date column sorts strangely, or some rows refuse to behave as dates, check for this split before you blame the data.

The third way is the non-date converted into a date: the range 1-2 becomes January 2, the ratio 5/6 becomes May 6, the code MARCH1 becomes March 1. Underneath, Excel stores a date as a serial number, the count of days since December 30, 1899, so March 4, 2026 is stored as 46085 and April 3, 2026 as 46115. Once a value has become a serial, the original characters are gone from that workbook. Formatting the cell as Text afterwards does not bring them back: it shows 46085, the serial rendered as text, not 2026-03-04. That is the test that separates a display problem from data loss. If the formula bar shows the serial, the characters are gone from that copy, and only the rescue section can help.

CSV file (from this page converter, verified):
order,shipDate,dueDate,window,code
A-101,2026-03-04,03/04/2026,1-2,MARCH1
A-102,2026-04-03,04/03/2026,12-3,SEPT2
A-103,2026-03-04T10:30:00Z,3/4/2026,5/6,OCT4

What Excel shows on double-click, US machine (month first):
shipDate -> real dates, displayed 3/4/2026, 4/3/2026, 3/4/2026
window -> 1-2 becomes Jan-02, 12-3 stays text, 5/6 becomes Jun-05
code -> MARCH1 becomes Mar-01, SEPT2 becomes Sep-02, OCT4 becomes Oct-04

What Excel shows on double-click, day-first machine:
dueDate 03/04/2026 -> April 3 (was March 4); 04/03/2026 -> March 4 (was April 3)
dueDate 3/4/2026 -> April 3 (was March 4); rows with day above 12 stay text

Notice what the table proves: nothing is missing from the file, and everything is changed in the Excel view. That is why the import fix works so completely. When you tell Excel a column is Text before loading, it stores the same characters with no conversion at all, and every date snaps back to itself, with no editing and no retyping. If your file matches this pattern, skip the myth-busting section and go straight to the import fix. You do not have a damaged file. You have a misread one.

Four fixes that do not work, and why people keep trying them

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 column after opening the file. Changing the number format changes how a stored date displays, but it cannot change which date was stored. If Excel stored April 3 when the file meant March 4, reformatting shows April 3 in a different style, and the wrong date stays wrong. Formatting is display. The stored serial is the data, and display changes never touch it.

The second is changing your system regional settings after the import. The settings matter at the moment Excel reads the file, not after. Once the serials are stored, switching the machine from month-first to day-first only changes how the stored serials display, exactly like reformatting. It does not re-read the file, and it does not unswap anything. The third is quoting the values in the CSV. Many guides claim that writing "03/04/2026" with quotes protects the date. It does not, in Excel. Excel strips the quotes during import and then applies the same date guess to the value inside, so the quoted date converts exactly like the bare one. Quoting controls how commas inside a value are handled, not how Excel types the value.

The fourth is find-and-replace on the converted dates, swapping month and day back by hand or by formula across the whole column. That works only if every row swapped, which is never the case: rows with day above 12 never swapped, they stayed text, so a blanket swap corrupts the rows that were right while fixing the rows that were wrong. Keep find-and-replace for values you typed by hand, and use the import fix for files. Knowing which fixes fail saves you from the most common trap of all: believing the problem is solved because the display looks right, while the stored values are still wrong.

Fix 1: import the file and set date columns to Text

This is the fix to try first, because it changes nothing about your system, nothing about the file, and it works on any CSV whatever its delimiter or encoding. Instead of double-clicking the file, open Excel first, then import the file through the guided import, where you choose the type of each column yourself. The preview in the import dialog shows you immediately whether you picked right: the dates display exactly as written in the preview, in the same characters as the file, before anything is loaded. If the preview still shows converted dates, you have not changed anything yet, and you can adjust the column types before loading.

• ▸Open a blank workbook in Excel. Do not double-click the CSV file.
• ▸Go to Data, then From Text/CSV, and select your file.
• ▸In the preview dialog, check the delimiter and the file origin, then click Transform Data instead of Load, to open the Power Query editor.
• ▸In the Power Query editor, find the automatic Changed Type step and remove it, because that step is where the date guess happens.
• ▸Select every date column, and every code column that looks like a date, and set the data type to Text.
• ▸Click Close and Load. The dates arrive as text, with every character exactly as written.

Text dates have one honest trade-off to understand. A text date is not a real Excel date: it will not sort chronologically with real dates, and date formulas will ignore it until you convert it deliberately. That is a feature, not a flaw, when the goal is preserving the source characters. Convert deliberately afterwards, with the next fix, once you know the source convention. Make importing your default way of opening CSV files, not just your rescue move. Double-clicking is a guess about the delimiter, the encoding, and the type of every column. Importing is a choice about all three, and the choice takes about a minute longer. On a Mac, the same route works through Data, then From Text, with the column types set in the import step.

Fix 2: import with the source locale, so the conversion is the one you intended

If you need real Excel dates, not text, the import route still works, with one extra step: tell Excel which convention the source file uses. In the Power Query editor, right-click the date column, choose Change Type, then Using Locale. Pick Date as the data type and the locale that matches the source file, English (United States) for month-first files, or the day-first locale that matches a European export. Power Query then converts every row under that one convention, including rows with day above 12, so the column comes out uniform: all real dates, no text stragglers, no silent swaps.

Check the result before loading, using the rows that betray a swap. Find records where the day is greater than 12: under the right locale they load as dates, under the wrong one they stay text or fail. Then find a record where day and month are both 12 or less and confirm it reads the way the source meant. If either check fails, you picked the wrong locale, and you have lost nothing, because nothing is loaded yet. Change the locale and check again. This two-record check takes ten seconds and catches the mistake that otherwise hides for months.

Fix 3: repair dates that were already imported, without re-importing

Sometimes re-importing is not an option, because the original file is gone and only the workbook survives. What you can repair depends on what survived. If the imported dates are still text, because Excel did not recognize them, the Text to Columns tool repairs them: select the column, go to Data, then Text to Columns, click Next twice, and on step 3 choose Date and the format that matches the original file, MDY for month-first or DMY for day-first. Excel converts the whole column under that one convention, which is exactly the control double-click never gave you.

If the dates were stored as the wrong serials, because every row swapped, a formula can swap them back: in a helper column, =DATE(YEAR(A2),DAY(A2),MONTH(A2)) rebuilds each date with day and month exchanged, and copying the results and pasting them as values locks the repair in. But this works only when every row in the column swapped, which means every original day was 12 or less. If the column is mixed, dates plus text stragglers, repair the two groups separately: convert the text rows with Text to Columns first, then check whether the date rows need swapping at all. A blanket formula on a mixed column corrupts the rows that were right. And if the original characters are gone and you cannot tell which rows swapped, stop: no formula can recover information the file no longer holds, and the rescue section is your only honest route.

Fix 4: turn off automatic date conversion, and write ISO dates at the source

If you open CSV files every day, importing each time gets old, and the durable fix is to change what Excel guesses by default. Recent Excel versions, Microsoft 365, Excel 2024, and their Mac equivalents, carry a setting called automatic data conversion, under File, then Options, then Data. It lists the conversions Excel applies on its own, including converting letter-and-number strings that look like dates. Uncheck the conversions you do not want, and Excel will leave those values as text on future opens, including double-click opens.

Two cautions before you rely on this setting. First, it changes future behavior only. It does not repair cells that were already converted, and it does not restore characters that were already replaced by serials. A file you opened last week still holds the converted values in the workbook, and only a fresh import from the original file will bring the dates back. Second, the setting lives on your machine, not in the file. A colleague who opens the same file on a machine with the default setting will still see converted dates, and a file you send out carries no protection with it. Treat the setting as a convenience for your own machine, and treat the import fix as the reliable method for files you share.

If you produce the CSV, the strongest fix is at the source: write dates in ISO 8601 form, year first, 2026-03-04. Year-first dates have no day-month ambiguity for any reader to resolve, because the year comes first and the month is always the middle number. That does not make Excel infallible, so still check the import, but it removes the entire class of swap errors that slash and hyphen dates invite. In JSON, that means keeping dates as strings in ISO form, not as locale-formatted strings: the string "2026-03-04" converts to the characters 2026-03-04, while a locale string like "03/04/2026" carries its ambiguity into every file it touches. This is a source-data decision, not a converter setting, because no converter can declare a convention the source never stated.

Rescue a file that was already saved with converted dates

So far every fix has assumed the file on disk is still correct and only the Excel view is wrong. But sometimes the converted version has already been saved, and the question becomes whether the original dates can still be recovered from the saved copy. The answer depends on exactly what the save did, and there are two cases to tell apart. In the first case, the file on disk still holds the original characters, and only the workbook display is wrong. That is the case the text-editor test detects: the editor shows the original dates, so nothing is lost, and Fix 1 repairs the view. In the second case, the file on disk now contains the converted values themselves, because someone opened it in Excel, saw the reformatted dates, and saved it back to CSV, writing the converted values into the file.

The second case is recoverable only in narrow circumstances. If every date swapped under one convention and every original day was 12 or less, the DATE formula from Fix 3 swaps them back, because the damage is a uniform exchange. Work on a copy, never on the only version, and check the result against a known record before opening it in Excel again. If the damage is mixed, some rows swapped, some rows stayed text, some codes became dates, the original characters are gone from that copy in a way no formula can untangle, because a serial number does not record which convention produced it. In that case, stop repairing the copy and 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 Fix 1. And whatever you do, keep the damaged copy aside until the regenerated file checks out. 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. The download preserves dates exactly as the JSON holds them. That was verified against the real code, not assumed: the conversion engine was run on a three row sample holding the ISO date 2026-03-04, the slash dates 03/04/2026 and 04/03/2026, the timestamp 2026-03-04T10:30:00Z, and the date-looking codes 1-2, 12-3, 5/6, MARCH1, SEPT2, and OCT4, and it produced every value byte-identically in the CSV, with no reformatting, no conversion, and no digits changed. So if your converted file shows changed dates in Excel, the conversion did not damage anything. The file is correct, and Excel guessed the types on double-click.

That gives you two clean options for converted files. The first is the import route: open the downloaded file with Data, then From Text/CSV, click Transform Data, set every date column to Text to keep the characters, or to Date with the source locale if you need real dates, and load. The dates will read correctly, and you have changed nothing about the file, so it stays valid for every other tool. The second is the automatic-conversion setting from Fix 4, for your own machine. Do not re-convert the data to fix a type-guessing display problem, and do not paste the converted output through a spreadsheet and save it back, because that round trip can introduce exactly the delimiter, encoding, and type mismatches this guide and its companions exist to prevent. Fix the opening, not the data.

One more converter detail matters here. The converter lets you choose the delimiter before downloading, and that choice is independent of type guessing. A file can have the right delimiter and swapped dates at the same time, or the right dates and the wrong delimiter, or both wrong at once. If your converted file opens in one column and the dates look wrong, fix both settings in the same import: pick the delimiter you chose at conversion time, and set the date columns to Text or to Date with the source locale. 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 dates so nobody has to fix them

Type guessing is a mismatch between writer and reader, so prevention means making the writer declare what the values are, in a way the reader will honor. Run through this checklist when you produce a CSV, and the next person who opens it will not need this guide. First, write dates in ISO 8601 form, year first, at the source. If your data holds dates, store them as ISO strings in the source system, because a locale-formatted date carries its ambiguity into every export. Second, if the audience is Excel, tell them how to open the file: a one-line note saying import with date columns set to Text, or to Date with the source locale, prevents the whole problem, and it costs nothing to include with the file.

Third, never save a rescued file back over the original until you have verified the rescue in a text editor. A save from Excel rewrites types, delimiters, and encoding with Excel own defaults, which can reintroduce the mismatch for the next reader, or turn a display problem into real data loss. Fourth, when you receive a file, open it in a text editor first if anything looks off, and confirm the dates before you let any spreadsheet save over it. And fifth, keep the source data. A CSV is a flattened snapshot, not the data itself, so if a rescue goes wrong, the source lets you export again cleanly instead of repairing a damaged copy. Most date horror stories end with someone discovering too late that the damaged CSV 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 Saving Your CSV in Excel Changes It, and How to Keep the Original Safe (2026 Guide) →
• Why Excel Won't Open Your Big CSV File, and What to Do Instead (2026 Guide) →

Frequently asked questions