Why our online tools never upload your files

There are dozens of "free online" PDF and image tools. Almost all of them work the same way: you drop a file, the file uploads to a server, the server runs the tool, and the result downloads back to your browser. The architecture is simple, and for a long time it was the only practical option.

It also has a problem. Your file is sitting on someone else's server, even briefly. If that server logs the upload, retains a copy for "operational purposes," shares data with an analytics partner, or gets compromised — your document is exposed. For documents you don't care about, that's fine. For tax returns, contracts, medical records, or screenshots from internal tools, it's not.

The browser caught up

Around 2017, a quiet shift happened. Browsers grew the ability to do things that previously required a server:

• WebAssembly runs near-native compiled code in the browser — fast enough for image processing, PDF rendering, and even on-device neural networks.
• The Canvas API can decode, draw, and re-encode images at any quality.
• The File System Access API lets a web page read files the user picks without ever sending them anywhere.
• SubtleCrypto computes hashes, signs payloads, and verifies signatures using hardware-accelerated routines.

Add up these primitives and most "I need to upload a file" workflows become "I'll just do it in the tab."

What this looks like in practice

Take PDF merging, our most popular tool. The traditional cloud version uploads each PDF, runs pdftk or qpdf server-side, and serves you the result. Our version loads pdf-lib — a pure JavaScript PDF library — into your browser, reads the bytes via the File API, calls mergePdfs in memory, and hands you a fresh Blob to download. Open the network tab while it runs: you'll see zero requests to our server during the operation. We literally cannot see your files because they never reach us.

The same pattern applies to every tool on this site. Image compression uses Canvas. Background removal runs an ONNX model in WebAssembly. JSON formatting uses JSON.parse. Hash generation uses SubtleCrypto. We're not relying on a server; we're relying on the browser.

Trade-offs

This approach isn't free. There are real downsides:

• First-load size. Each tool ships with its engine. We mitigate this with lazy loading — the JSON formatter doesn't ship pdf-lib.
• CPU is yours. A 100-page PDF compress takes a few seconds on a phone. On a server it would be instant. Your device works harder.
• Memory limits. Browser tabs cap out around 4 GB on most desktops, less on mobile. Truly enormous files (5 GB videos, multi-gigabyte PDFs) don't fit.
• No persistent state. No "save to cloud" without adding a third-party service. We accept this; the privacy benefit outweighs the convenience.

For 99% of everyday file work — the documents most people actually have — these trade-offs are imperceptible. And the win is significant: you can use the tools without thinking about whose data policy applies, whose server the file just visited, or which logs it might appear in.

Why we chose ads instead of accounts

Running this site costs almost nothing — Vercel's free tier handles thousands of users a day, and we don't need any backend. Display ads cover the small overhead. We've seen friends launch similar tools with subscription tiers and account systems, and inevitably the focus shifts to engagement, retention, and squeezing more out of fewer users. Ads-with-no-account keeps the incentives aligned: more users → more revenue, with no one needing to give us anything but a URL bar.

If your day-to-day involves files you'd rather not send to strangers, give a browser-based tool a try. We think you'll be surprised how much can happen entirely on your machine.