Don’t take our word for it — test it yourself

Every converter site on the internet says your data is safe. The sites that upload your file to a server say it. The sites that sell your data would say it too. A privacy claim is worth nothing — so this page shows you three ways to verify, on your own machine, in under a minute, that a file you drop on CSVUndo never leaves your browser tab. You don’t need to be technical for the first one.

1. The 30-second test: go offline first

An upload needs a network. Take the network away and an upload site dies instantly — but CSVUndo keeps working, because there was never a server involved.

  1. Open any tool page — say the CSV repair tool — and let it load.
  2. Now disconnect: on Windows, click the network icon in the taskbar and switch on Airplane mode (or toggle Wi-Fi off). On a Mac, click the Wi-Fi menu and turn Wi-Fi off. On a phone or tablet, swipe into quick settings and tap Airplane mode.
  3. Drop your CSV on the page, click through the analysis, download the repaired file.

It all works. Nothing even slows down. A site that uploads your file cannot do this — try the same test on any “free online converter” and watch it fail the moment you disconnect.

2. Watch your browser’s own network log

Your browser records every single byte a page sends anywhere. That log is a couple of keystrokes away, and it cannot be faked by the page you are watching:

  1. Open the repair tool, then press F12 (Chrome and Edge) or Ctrl+Shift+E (Firefox). On Safari, enable the Develop menu in Settings → Advanced first, then press Cmd+Option+E.
  2. Click the Network tab in the panel that opens.
  3. Drop a CSV on the page and run the repair.

Here is what you will see — the page’s own files loading once, and then nothing, no matter what you do with your file:

NameMethodSizeWhen
index.htmlGET21 KBpage load
style.cssGET14 KBpage load
repair.jsGET38 KBpage load
— you drop your file, analyze it, repair it, download it —
(no new rows. ever.)

If this site uploaded your file, a request would appear in that list the moment you dropped it. There is no way to hide a request from this panel — it is your browser reporting on us, not us reporting on ourselves.

3. The browser is the bouncer: our CSP header

The two tests above show what the site does. This one shows what the site is allowed to do. Every page here ships with a Content-Security-Policy header — a rule list your browser enforces against us. The load-bearing directive:

connect-src 'none'

In plain English: this page is forbidden from making a network request to anywhere at all — not to someone else’s server, and not even back to ours. Most privacy-minded sites set this to 'self', which still permits the page to phone home to its own origin. We can afford the stricter setting because this site genuinely makes no requests after the page has loaded: there is no fetch, no XMLHttpRequest, no sendBeacon and no form anywhere in the code.

So even if our JavaScript tried to upload your file — even if the code were tampered with to try — your browser would refuse the request and log a violation in the console. That is the difference between a promise and a guarantee: it is not us telling you we behave, it is your browser refusing to let us misbehave. You can see the full header independently scanned at securityheaders.com.

And because every line of JavaScript on this site ships unminified with no build step, View Source shows you the exact code that runs. The engine is one readable file: assets/repair.js.

What we can and cannot see

Honesty cuts both ways, so here is the full picture: like any website, the server that hosts these pages sees that your browser visited them — standard web logs with IP addresses and timestamps exist at the hosting layer. What no server ever sees is the contents of your files: the file is opened by JavaScript inside your tab, repaired in your tab’s memory, and saved from your tab to your disk. Full details in the privacy policy.

Ready when you are: repair a CSV, or browse all ten tools. Wi-Fi optional.