You can clean a messy CSV with ChatGPT or Claude safely if you work on a copy, ask the model for cleaning rules instead of a rewritten file, and spot-check dates, names and duplicates before you apply anything. Never let it touch your only copy.
Every spreadsheet person knows the file. It came from three systems, two countries, and one intern who typed dates however they felt that week. The export has "Acme Corp", "ACME Corp", and "acme corp" in the same column, and half the dates are 03/04/2026 while the other half are 2026-04-03.
The temptation in 2026 is to drag the whole thing into ChatGPT or Claude and say "clean this." That works often enough to be dangerous, because when it fails it fails silently: the file comes back tidy, confident, and quietly wrong in places you will not discover until the quarterly report. The fix is not to avoid AI for data cleaning. It is to never let the model touch your only copy, and to make it hand you rules instead of rewrites.
Rule zero: never upload the only copy
Before any AI sees your data, duplicate the file. Not "save as later", right now, an actual copy with a name like orders_raw_backup.csv that nothing will ever write to again.
This matters more with data cleaning than with almost any other AI task. When a model summarizes a document, a bad answer is obviously bad. When it cleans a CSV, a bad answer looks exactly like a good one: neat columns, consistent formatting, plausible values. The failure mode is not an error message. It is a clean-looking file with wrong dates and missing rows.
There is a second reason. OpenAI's own help center notes that a file may upload successfully but still be too large or poorly structured for complete analysis. A model working on a 60,000-row export may effectively process a sample and generalize. If it rewrites the file it hands back, the rows it never really read are now "cleaned" too.
And if the data has anything sensitive in it, customer names, salaries, health records, strip those columns before upload. Cleaning a date column does not require anyone's credit card number.
The safe loop: sample, rules, spot-check, apply
The core trick is to invert the usual request. Do not say "clean my file." Say "look at a sample of my file and tell me the rules you would use to clean it." Then you check the rules, and only then let anything touch the data.
Step 1: Send a sample, not the file. Take 20 rows that include the worst offenders: mixed date formats, trailing spaces, one duplicate, a name in ALL CAPS. Twenty rows is small enough to verify cell by cell with your own eyes, and representative enough that the model sees the real patterns. Paste it directly into the chat rather than uploading, so the output cannot be mistaken for the master file.
Step 2: Ask for rules, not a rewrite. Something like:
"Here are 20 rows from a CSV. Do not rewrite them yet. List every inconsistency you find and the exact rule you would apply to fix each one. Where a rule is ambiguous, tell me what you would need to know instead of guessing."
This is where the model earns its keep. A good response comes back looking like: trim leading and trailing whitespace; collapse "USA", "U.S." and "United States" to one value; dates are mixed DD/MM/YYYY and YYYY-MM-DD, which is which; rows 4 and 11 are duplicates on order ID, keep the earlier one. Rules you can actually argue with.
Step 3: Argue with the rules. This is the spot-check, and it is the step people skip. The model will make assumptions. It will decide your European dates are American, or that two rows with the same customer ID are duplicates when they are actually two orders. Correct the rules in chat before any data changes. On the sample, this costs seconds.
Step 4: Apply the approved rules, on the copy. Two good ways. One: ask the model to produce the cleaned version of the sample, compare it cell by cell against what you expected, and only then run the full file through the same conversation. Ask for a cleaned copy, keep the original file unchanged, and have the model list what it changed before you use the result. Two, and better for anything recurring: ask for a formula or a script instead. A =TRIM() helper column, a Power Query step, or a short Python script is deterministic. It does the same thing every time you run it on next month's export. A chat session does not.
The date column it would have wrecked
Here is a concrete example of why the spot-check step exists. Take this 20-row sample of an order-date column, the kind that comes out of a merged export:
| order_id | order_date |
|---|---|
| ORD-101 | 03/04/2026 |
| ORD-102 | 2026-04-03 |
| ORD-103 | 21/05/2026 |
| ORD-104 | 07/12/2026 |
| ORD-105 | 15/11/2026 |
Rows 103 and 105 give the game away: there is no month 21 and no month 15, so those must be DD/MM/YYYY, day first. That means row 101 is almost certainly April 3rd, not March 4th, and row 104 is December 7th, not July 12th. But rows 101 and 104 are exactly the cells that parse as valid dates under either interpretation. A model told to "standardize the dates" without this discussion will often pick one convention for the whole column, and half the dates come back months off. No error. No warning. Just wrong.
The safe-loop version catches it at step 3: the model reports "this column mixes DD/MM/YYYY and YYYY-MM-DD", you confirm day-first from the unambiguous rows, and the rule becomes "convert everything to ISO 8601 (YYYY-MM-DD), treat slash dates as day-first, flag any cell that cannot be parsed instead of guessing." The before and after is boring, which is the point:
| order_id | before | after |
|---|---|---|
| ORD-101 | 03/04/2026 | 2026-04-03 |
| ORD-103 | 21/05/2026 | 2026-05-21 |
| ORD-104 | 07/12/2026 | 2026-12-07 |
ISO 8601 is the right target format because it is the one date format with no regional interpretation. It also sorts correctly as plain text, which your downstream tools will appreciate. Excel users get the same propose-and-approve pattern in-sheet. Microsoft's support page says Clean Data, on the Data tab, is available to Copilot customers and suggests fixes for inconsistent text, inconsistent number formats and extra spaces, which you accept with Apply or skip with Ignore. The AI proposes, you dispose.
Dates, names, dupes: what AI actually breaks
Three categories cause nearly all the damage.
Dates are the worst, as above, because ambiguity is invisible. Any date where the day is 12 or below can be silently transposed. The detection heuristic is worth memorizing: in a real year of data, a large share of the dates should have a day value above 12. If none do, your column has probably been flipped.
Names and categories break in two directions. The model over-normalizes, turning "Anna K. Schmidt" and "Anna Schmidt" into one person. Or it under-normalizes because you did not tell it that "NYC" and "New York" are the same place. The rule to give it: standardize formatting only, and produce a "review needed" list when deciding whether two entities are the same. Entity matching is a business decision dressed up as a text problem.
Duplicates are where deletion happens, and deletion is the only cleaning operation that cannot be undone by fixing a format. Never accept "I removed the duplicates" as a final answer. Ask which rows, on which key, how many. If the model cannot show you the removed rows, do not trust the removal.
What to keep manual
Some jobs should not go to the model at all, even on a copy. Deciding whether two customer records are the same human. Anything involving IDs that must never change. Filling in missing values by inference: imputing a blank revenue cell is manufacturing data, and it will look exactly as credible as your real numbers downstream. And the final read-through: sort each cleaned column, check the min and max, confirm the row count dropped by exactly the number of duplicates you approved and not one row more.
A short verdict
AI is genuinely good at the tedious 80 percent of CSV cleaning: whitespace, casing, format standardization, splitting combined fields, flagging what it cannot parse. It is genuinely bad at the judgment 20 percent: which convention produced a date, whether two rows are the same thing, whether a missing value can be inferred. The safe loop, copy the file, sample the mess, demand rules, spot-check, apply approved rules, gets you the first 80 percent without exposing yourself to the second. If you are choosing between chat models for this kind of work, our Claude vs ChatGPT guide covers the trade-offs, and the prompting patterns in our prompt improvement piece transfer directly to data tasks. And if this failure mode feels familiar, it is the spreadsheet version of the classic mistake of automating a process before verifying it works.
Next step: copy your file, paste 20 of its worst rows into a chat, and ask for rules before you let the model change a single cell.




