Why I Built File Tools That Don't Upload Your Files

I compressed a PDF with a popular online tool last year. Out of habit, I opened the browser DevTools network tab. I watched my 12 MB file leave my machine and land on someone else’s server. A POST request to some AWS endpoint. My file, a contract with names, addresses, and signatures, sitting on infrastructure I know nothing about.

That moment stuck with me.

The Upload Tax on Every “Free” Tool

Go search for “compress PDF free” or “convert JPEG to PNG” right now. The top results are all the same pattern: ILovePDF, TinyPNG, SmallPDF, CloudConvert. They look different but they all do the same thing under the hood.

You drop your file. It gets uploaded to their server, usually S3 or equivalent. A serverless function (Lambda, Cloud Run, whatever) processes it. The result gets sent back to you. Your original file sits on their infrastructure.

Read their terms of service sometime. Many grant themselves broad rights to “process” and “store” your files for “service improvement.” Some claim they delete files after an hour or a day. Maybe they do. Maybe they don’t. You have no way to verify.

“Files are automatically deleted after 2 hours.” Sure. But they already left your machine. The damage window is open.

This isn’t a conspiracy theory. Data breaches happen constantly. In 2023 alone, billions of records were exposed across various cloud services. Your “quick PDF compression” is now part of someone’s attack surface.

The Question Nobody Asks

Here’s what bothered me most: why does compressing a PDF need a server at all?

Think about what these tools actually do. Converting a JPEG to PNG is matrix math on pixel data. Formatting JSON is parsing and re-serializing a string. Compressing a PDF is optimizing embedded images and removing redundant objects. Generating a QR code is running an encoding algorithm.

These are pure computation tasks. They don’t need a database. They don’t need an API. They don’t need the cloud. Your laptop has more than enough processing power to handle every single one of them.

The only reason these tools upload your files is because that’s how web apps have worked historically. Server does the work, browser shows the result. But that hasn’t been the only option for years now.

Building Everything Client-Side

I decided to build Vault-Tools with one non-negotiable rule: files never leave the browser.

The technology that makes this possible is WebAssembly. I write the processing logic in Rust, a systems programming language built for performance and memory safety, and compile it to Wasm. That Wasm module runs directly in your browser tab, in a sandboxed environment. It can’t access your filesystem. It can’t make network requests. It just processes the bytes you give it and returns the result.

The pipeline is simple:

1. You drop a file
2. JavaScript reads it into memory
3. The bytes go to the Wasm module
4. Wasm processes them and returns the result
5. JavaScript creates a download

No upload. No server. No network request. The entire operation happens in the same browser tab where you’re reading this.

What It Cost

I’m not going to pretend this was easy.

Rust has a steep learning curve. The borrow checker is unforgiving. Finding Wasm-compatible crates for every operation took serious research; not every Rust library compiles to the wasm32-unknown-unknown target. I had to pin the PDF library (lopdf) to version 0.35 because newer versions don’t compile to Wasm at all.

Some problems were genuinely hard. HEIC image decoding has no pure-Rust solution that works in Wasm, so I had to build a hybrid approach: an npm package handles the decoding in JavaScript, then passes the pixel data to the Wasm module for encoding. PDF rendering to images required creative workarounds. Font embedding for page numbers and watermarks meant subsetting a 400 KB font file down to 26 KB to keep the Wasm binary reasonable.

There’s no server-side fallback. If a browser doesn’t support Wasm (virtually none at this point, but still), the tool simply won’t work. I accepted that trade-off.

Beyond Privacy: The Performance Argument

Here’s what surprised me: privacy wasn’t the only win. The client-side approach is faster for almost every use case.

When you compress a PDF on a server-based tool, here’s what happens: upload 15 MB over your connection (maybe 10-30 seconds), wait for the server to process it (seconds to minutes depending on queue), download the result (more seconds). The actual compression takes milliseconds. You’re spending 95% of the time on network overhead.

With Vault-Tools, you drop the file and the result appears in seconds. There is no application-level upload cap; practical limits depend on browser memory and device performance. There’s no upload queue because there’s no server.

It also works offline. Once the page loads and the Wasm module is cached, you can disconnect from the internet entirely. Try that with ILovePDF.

45 Tools, Zero Uploads

This approach now powers over 45 tools across five categories:

• Image tools: convert formats, compress, resize, strip EXIF data, generate favicons, extract color palettes
• PDF tools: compress, merge, split, add page numbers, edit metadata, convert to images
• Text tools: format JSON, convert CSV, encode Base64, render Markdown, diff text
• Dev tools: generate hashes, decode JWTs, create QR codes, convert timestamps, generate UUIDs
• File tools: calculate checksums, convert TSV/CSV, compress to ZIP

Every single one runs entirely in your browser.

Verify It Yourself

I don’t ask you to trust me. I ask you to verify.

Open any tool on vault-tools.com. Open your browser’s DevTools (F12 or Cmd+Option+I). Go to the Network tab. Clear it. Now process a file.

Watch. Count the requests. You’ll see zero file uploads. Zero POST requests with your data. The Wasm module loads once (that’s the tool itself, not your data), and after that, nothing leaves your machine.

That’s the whole point. Your files are yours. A tool that processes them shouldn’t need to see them.

I built Vault-Tools because I got tired of the upload tax. Because “free” tools that monetize your data aren’t really free. Because the technology to do this entirely in the browser has existed for years and nobody was using it for the tools people actually need.

Your files stay on your machine. Verify it yourself.