Here's a thing most people never think about: when you drag a PDF into a "free online merge tool," that file leaves your computer. It travels to a server you've never heard of, owned by a company you didn't check, in a country you didn't pick. Your contract, your tax return, your kid's medical form — uploaded, processed, and maybe deleted. The privacy policy will say "we delete files after an hour." You have no way to know if that's true, and no recourse if it isn't.
For a task that is, computationally, trivial. Merging two PDFs is something your laptop can do in the time it takes the upload progress bar to appear.
That gap — between how simple the task is and how much of your data these tools quietly harvest to do it — is what got under my skin. So I started rebuilding the ones I used most, with a single rule: the file never leaves the browser.
"Client-side" isn't a marketing word here
Modern browsers can do a startling amount on their own. The File API reads your file into memory. Libraries like pdf-lib manipulate a PDF in JavaScript. The Canvas and MediaRecorder APIs capture and encode video. None of it needs a round trip to a server, because the browser tab is the computer doing the work.
So the PDF tool merges, splits, rotates, and converts without a single network request after the page loads. Same idea for the screen recorder — it uses the native getDisplayMedia and MediaRecorder APIs to capture and save an MP4 locally, so there's no 5-minute cap, no watermark, and no upload, because there's nowhere to upload to.
Here's the part I like best, and the part that makes this claim different from every "we respect your privacy" banner: you can verify it yourself in about ten seconds. Open your browser's DevTools, switch to the Network tab, and use the tool. Process a file, record your screen, whatever. Watch the request list. It stays empty. There's no trust required — the proof is right there in the browser you already have open.
Try doing that on a typical online converter. You'll watch your file go up.
It's not just about privacy — it's faster and it works offline
The privacy angle is the reason I started, but the practical wins turned out to be just as good:
- No upload/download round trip. A 40 MB PDF that takes 30 seconds to upload and re-download is instant when the work happens in place.
- No file-size limits or queues. There's no server to overload, so there's no "upgrade to Pro for files over 10 MB."
- It works on a plane. Once the page has loaded, you can kill your wifi and everything still runs. Try that with a cloud tool.
Even the boring developer stuff benefits. A CSV-to-JSON converter has no business seeing your data — half the time the CSV I'm converting is a customer export I'm not allowed to paste into a random website in the first place. Doing it locally isn't a nice-to-have there; it's the only version I can actually use at work.
The takeaway isn't "use my tools"
It's this: for any task that only touches your data and doesn't genuinely need a server — file conversion, formatting, encoding, resizing, recording — the correct default is client-side. If a tool for one of those jobs is uploading your file, ask why. Usually the answer is "so we can show you ads and rate-limit you into a subscription," not "because it was technically necessary."
The web platform got good enough to do this stuff locally years ago. More tools should.
I've been slowly rebuilding the ones I reach for at cyzorcreations.com/tools — all free, all in the browser, none of them ask for an account. But honestly, whether you use those or someone else's, the habit worth building is the same: check the Network tab before you upload your file to something. You'll be surprised how often you don't have to.
Top comments (0)