I Replaced My CSV Cleanup Script With Four Browser Tools

I had a recurring little problem that was too small for a data project and too annoying for a manual fix: a CSV export would arrive with duplicated contacts, opaque column names, and fields nobody on the receiving end actually needed. My old answer was a small script. It worked, but it turned a five-minute handoff into a context switch: find the repo, remember the command, check the output, then explain what I did.

This week I replaced that detour with a four-step browser workflow from Tiny Online Tools. My goal was not to build a data pipeline. It was to turn an operational CSV into something a colleague could review without creating a new account, installing software, or sending the file to a mystery converter. The site positions its utilities as browser-based with no uploads, accounts, or tracking, which made it a sensible fit for the mundane-but-sensitive exports I deal with.

The small outcome I cared about

The deliverable was simple: one clean CSV containing a known set of columns, one row per record, and headers that a non-technical teammate could understand. That is a much better target than “fix the file.” It gave me four checks:

Can I see what I actually received?
Can I remove repeat rows without guessing?
Can I translate source-system headers into business language?
Can I hand over only the fields needed for the next decision?

That sequence matters. I have made the opposite mistake: filtering before understanding the data, then discovering the identifier I needed was gone. For a larger recurring job, I would still automate and test it. But for an occasional export, a focused browser tool can be the lower-setup-cost option.

Step 1: Inspect before changing anything

I start in the CSV Viewer. This is the stage where I look for obvious surprises: a header row that is really data, blank columns, unexpected delimiters, date formats, or a column that only looks unique. I do not treat the preview as a quality guarantee; it is just a fast way to decide what the cleanup rules need to be.

The useful habit is to write down the handoff schema before touching the file. For example: customer_id, email, plan, and renewal_date. That short list is the contract. It keeps “maybe useful later” columns from quietly making it into an internal report or a client handoff.

Step 2: Deduplicate on a deliberate key

Next I use the CSV Deduplicator. The tool exists to remove duplicate rows, but the decision is mine: what counts as the same record? A repeated email may be a duplicate for a campaign list, while the same email with two subscription IDs may be legitimate for billing analysis.

My practical rule is to choose the identifier that matches the decision the recipient will make. If the recipient needs one outreach row per person, I use the person-level identifier. If they need a record per active subscription, I do not collapse those rows. That one sentence of intent prevents most accidental data loss.

I also keep the original export until the recipient has confirmed the result. Browser convenience is not a substitute for reversibility.

Step 3: Rename headers while the source context is fresh

The CSV Column Renamer is my bridge between a system export and a useful business artifact. I rename only when it lowers interpretation cost. cust_email becomes email; sub_state becomes subscription_status. I do not turn every machine-friendly field into prose, because that makes later reconciliation harder.

A good compromise is a compact mapping note in the delivery message: “subscription_status was exported as sub_state; records were deduplicated by customer_id.” That is enough provenance for a small operational handoff. It is the same review-first discipline I use when automating a Shopify blog workflow: make the transformation visible before someone acts on it.

Step 4: Extract the fields the next person needs

Finally, I use the CSV Column Extractor to create the handoff file. This is where I enforce the schema I wrote down in step one. The smaller file is easier to scan, less likely to expose irrelevant data, and more likely to be used.

This was the highest-leverage change. A tidy full export is still a full export. A decision-ready subset tells the recipient exactly what the file is for. It is also why clean catalog data pays off downstream: I have used the same idea when building reviewable catalog video queues and when adding approval gates to a Shopify catalog video process.

When this approach wins—and when it does not

I now use this browser stack when the file is one-off or lightly recurring, the transformation is understandable by inspection, and I want the work to remain local to the browser. It is also a nice fit for support, sales ops, marketing, and founders who need a clean export now, not a new tool rollout.

I go back to a scripted or warehouse workflow when volume is large, the rules need version control, several people must reproduce the result, or the CSV becomes an upstream dependency. In that case, manual browser steps are the wrong kind of fragile. My own weekly operations-review approach benefits from documented, repeatable inputs.

The point is not that every CSV deserves four tools. It is that tiny, explicit transformations often beat an oversized workflow. Try the Tiny Online Tools catalog with your next messy export: preview it, pick the deduplication key, rename only the confusing headers, and extract the fields the recipient needs. If that takes less time than opening your usual spreadsheet or script, bookmark the exact tools and keep the workflow small.