Browser-Based Tools vs Online Uploads: A Safety Comparison

Two ways to convert files online

You open a converter, drop in a file, get a result back. That part feels the same everywhere. What happens in the middle is the whole story, and there are only two possibilities:

Option A: upload to a server

The old-school way. Your file travels over the internet to a company's server, their software does the work, and the result comes back to you. The file existed on their machine, if only for a minute.

Examples: most of the big names, iLovePDF, Smallpdf, CloudConvert, and dozens of smaller sites.

Option B: process in the browser

The newer approach. Your file stays on your computer. JavaScript, usually compiled to WebAssembly, runs the conversion inside the page, on your device. The site only sent you the program, not your data.

Examples: FileMint, the PDF.js family of tools, and other privacy-focused apps. If you want the deeper technical reasoning behind this shift, our guide on client-side processing and privacy goes further.

Why does this matter?

A meme you are resizing for a group chat? Nobody cares. But the documents people actually run through these tools are rarely memes. They are the things you would never hand to a stranger on the street.

• A lawyer compressing a contract with a client's financial details
• A doctor converting a patient's medical records
• A student merging a scholarship application with tax documents
• A business owner editing invoices that show customer payment information
• Anyone converting private photos they would rather keep private

In every case the person just needs a file tool. They are also handling information with real value to data brokers, hackers, and identity thieves. The breach headlines are not hypothetical. In 2019 a form-builder site left an Amazon S3 bucket exposed with hundreds of thousands of user-uploaded documents, including passports, pay stubs, and Social Security numbers (TechCrunch). In 2025 the Dutch authority fined Uber €290 million for moving EU drivers' personal data to the US without proper safeguards (EDPB). None of that started with malice. It started with a file being uploaded somewhere.

What happens when you upload

When you use an upload-based service, your file takes a journey:

1. Your file travels through the internet, passing through multiple network nodes, ISPs, and potentially CDNs
2. The server receives and stores your file, at least temporarily
3. Server-side software operates on your file
4. The result travels back to you
5. The server (hopefully) deletes your files, but when? How thoroughly?

What happens with browser-based tools

When you use a browser-based tool, the journey is much simpler:

1. The website loads the processing code into your browser
2. You select a file from your computer
3. Your browser processes the file entirely on your device
4. The result is saved to your downloads folder

Notice what's missing? Your file never left your computer.

The offline test

Want to know, for sure, whether a tool is browser-based or just pretending? Cut the cord. The airplane-mode test takes thirty seconds and needs no technical skill:

1. Visit the tool and let the page fully load
2. Turn on airplane mode or unplug the WiFi
3. Try to process a file

If it works with no connection, the processing was genuinely local. If it throws connection errors, your files were being shipped somewhere. For PDFs specifically, see our guide on merging PDFs without uploading.

Speed, privacy, and the tradeoffs nobody mentions

Local is not always faster. For a tiny file, running in your browser wins because there is no upload round trip. For something huge, a server with more memory will finish sooner. The honest tradeoff table looks like this:

So which should you pick?

Reach for a browser-based tool when:

• You are processing sensitive or confidential documents
• You are working with personal photos or private data
• Corporate policy restricts sharing data with third parties
• You want to work offline
• Privacy matters more to you than a few seconds of speed

Uploading might be acceptable when:

• The file is public or genuinely non-sensitive
• The file is so large your device struggles with it locally
• You need a feature that only exists server-side
• You have read and trust that specific service's privacy practices

The local-first movement, laid out in the Ink & Switch paper Local-first software, argues that your device should hold the primary copy of your data, with servers as a backup at best. Browser tools are the lightest expression of that idea. If you handle other people's data, the GDPR data-minimisation principle (Article 5(1)(c)) pushes you the same direction, toward processing as close to the source as possible (EDPB). When the file is a photo, also read our guide on why images look blurry after converting before you ship it anywhere.

The bottom line

The difference is plain. Upload-based tools ask you to trust that they will handle your data well. Browser-based tools never receive it, so trust is not part of the deal at all.

For a throwaway file, it barely matters. For anything with weight to it, a legal doc, a medical record, a bank statement, private photos, the local option is the safer one. The data sits on your device, which means there is nothing on a server to leak in the first place. Try the browser-based tools and watch the Network tab stay empty. That silence is the feature.