I Built a CSV Cleaner That Explains Every Deleted Row

Deleting a duplicate row is easy. Explaining why the output has fewer rows is
the harder product problem.

I ran into that distinction while packaging a small Windows CSV cleaner. A
typical cleanup script can trim whitespace, drop empty rows, and remove
duplicates in a few lines. But when the input has four rows and the output has
two, the person using it still needs answers:

• Was the original file changed?
• Which rule removed each row?
• Did every file finish?
• Can I inspect the result without rerunning the job?

That changed the design. The audit report became a first-class output rather
than an optional log written after the "real" work.

Start with a reconciliation rule

The most useful invariant is simple:

input rows = output rows + blank rows removed + duplicate rows removed

The header is tracked separately. A duplicate can mean either an exact repeated
row or a repeated value in one or more key columns chosen by the operator.

If that equation does not balance, the run should not quietly display
"success." It has lost the ability to explain the output.

For each CSV, the cleaner records the input count, output count, blank-row
count, duplicate count, failure state, detected encoding, and original file
hash. A run summary then aggregates success and failure across the batch.

This is intentionally narrower than a general data-cleaning platform. It does
not guess what a broken address should be, rewrite phone numbers, edit Excel
workbooks, or use AI to infer missing values. The rules are deterministic so
the evidence can be checked.

Never make the original the rollback plan

An undo button is not a substitute for leaving the source file alone.

The program creates a new run directory and writes cleaned files there. The
input CSV remains untouched. Before processing, it calculates the original
SHA-256 and includes that value in the report.

That hash is not proof that the content is correct. It answers a narrower,
useful question: "Is this the same input file I intended to clean?"

The output is written as UTF-8 with a BOM because it opens predictably in common
Windows spreadsheet tools. The input reader accepts UTF-8, UTF-8 with BOM, and
CP949. Unsupported formats fail explicitly instead of being guessed into
plausible-looking text.

Treat the report as a product output

The run folder contains three different kinds of evidence:

• report.html for a person reviewing the run;
• summary.json for another program reading aggregate results;
• run_log.jsonl for chronological success and failure events.

The HTML report is the first thing I open after a run. It shows which file was
processed, the input and output counts, the removal reasons, the encoding, and
whether the file failed. The JSON files exist for automation, but the human
report keeps verification from requiring Python or a log viewer.

Open the actual fixed-sample HTML report.

That public report uses bundled test data. It is safe to inspect, but it is not
a claim that unrelated CSV files will produce the same numbers.

Isolate failures in a batch

Batch processing creates another easy failure mode: one bad file can hide the
results of all the good files.

The cleaner processes each file independently. If one file cannot be decoded,
has an invalid duplicate-key column, or exceeds a product limit, that failure is
recorded for the file while eligible files continue. The final summary reports
both counts.

This matters because "the window stayed open" and "every file succeeded" are
different facts. A useful batch result has to make partial success visible.

I also avoided writing a cleaned file before the input contract is accepted.
For example, the free edition checks its row limit before writing an output.
Rejecting an oversized file after creating a partial result would make the
folder harder to interpret.

Test the packaged program, not only the source tree

A passing development folder does not prove that the downloadable ZIP contains
the right executable, samples, documentation, and runtime files.

For the public sales build, I extracted the ZIP into a fresh directory and ran
the packaged Windows executable. The release contract passed 32/32 automated
tests, including UTF-8, UTF-8 BOM, CP949, exact duplicates, key-column
duplicates, empty rows, original preservation, failure isolation, and the free
edition's 101-row rejection path.

I then ran one fixed local sample through the packaged product:

• 1 CSV succeeded and 0 failed;
• 4 input rows became 2 output rows;
• 1 blank row was removed;
• 1 duplicate was removed using order_id;
• the original stayed untouched;
• the HTML report reconciled the counts.

The 51-second clip starts from a fresh ready state, selects the bundled sample,
runs the cleaner, and opens the generated report. It demonstrates that one
reproducible path; it is not a benchmark or a promise about every CSV.

Try the same workflow for free

I published a free Lite edition so the first test does not require a purchase:

Download CSV Audit Cleaner Lite from the public GitHub release.

It processes up to 100 data rows per CSV and uses the same cleanup and evidence
workflow. The ZIP includes the Windows executable, a sample CSV, quick-start
instructions, license, and checksum. It does not require installation, Python,
a cloud account, a subscription, or a paid API.

The README publishes the release size and SHA-256 so the download can be checked
before use. As with any data tool, keep backups and review the report before
putting cleaned files into a production workflow.

What the paid edition changes

The full edition removes the per-CSV row limit and includes the complete source
code and a commercial-use license. It is a finished download, not custom
development or a remote setup service.

The full product page
offers Personal for $15 one time and Team for $49 one time. It does not
include custom cleaning rules, Excel editing, ongoing support, or a future-update
commitment.

There are no customer reviews or market-validation claims yet. The evidence I
can publish today is narrower: the packaged program, the fixed sample, the
report, the downloadable Lite edition, and the test contract.

That is also the main lesson from building it: a cleanup tool becomes easier to
trust when deletion is not the final output. The result needs an explanation
that survives after the window closes.