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.
- Open any tool page — say the CSV repair tool — and let it load.
- 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.
- 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:
- 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.
- Click the Network tab in the panel that opens.
- 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:
| Name | Method | Size | When |
|---|---|---|---|
| index.html | GET | 26 KB | page load |
| style.css | GET | 20 KB | page load |
| repair.js | GET | 105 KB | page load |
| analytics.js | GET | 3 KB | page load |
| — you drop your file, analyze it, repair it, download it — | |||
| (no new rows. ever.) | |||
Those are the uncompressed file sizes; DevTools will show smaller numbers in its Size column because the server sends them compressed. The part that matters is the number of rows, not their weight: four requests when the page loads, and then none.
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 opening any data connection — fetch, XMLHttpRequest, WebSocket or sendBeacon — to anywhere, including back to us. 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 if our JavaScript tried to upload your file, your browser would refuse the request outright and log a violation in the console — and that holds for every ordinary route a website has for sending a file somewhere. 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.
Being exact about the edge of that guarantee, because this page is about evidence rather than reassurance: connect-src governs data connections, not images or page navigations. It shuts off every upload path a website would actually use — it is not a claim that no byte of any kind can ever leave a browser tab. The Network-panel test above is what shows nothing else is happening either, and 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 14 tools. Wi-Fi optional.