Why Browser-Based Tools Are Safer for Your Files

When you use a typical "free online converter", your file is uploaded to someone else's server, processed there, and — if the operator keeps their word — deleted afterwards. For a meme, who cares. For a contract, a payslip, a passport scan or a medical record, that upload is a real and entirely avoidable exposure.

This article explains what the alternative actually is, how to verify any tool's claim yourself in about thirty seconds, and where browser-based processing genuinely falls short. That last part matters: a privacy argument that only lists advantages is marketing, not information.

Two architectures, and only two

Behind every "online tool" there is one of two designs.

Server-side. You select a file, your browser transmits it to the operator's infrastructure, the work happens on their machines, and the result is sent back. This is how most mainstream services work, and their own privacy policies describe the upload and the retention window. It handles enormous files well and needs almost nothing from your device.

Client-side. The tool's code is downloaded to your browser once, and every subsequent operation happens on your own hardware using JavaScript and WebAssembly. The file is opened by your device, transformed on your device, and saved back to your device. Nothing is transmitted.

Every tool on Filevane uses the second design. When you merge a PDF, compress an image or password-protect a document, the bytes never traverse the network.

Why the difference matters more than it sounds

There is no server copy to leak. Breach disclosures routinely involve data the company had legitimately collected and simply still held. A file that was never uploaded cannot appear in a breach, cannot be subpoenaed, and cannot be retained past a policy change.

"Deleted after one hour" is a promise, not a property. It is a meaningfully better promise than nothing, and reputable operators keep it. But the file still crossed the internet, still landed on hardware you do not control, and was still readable there by anyone with access. Client-side processing removes the question rather than answering it — there is nothing to delete because nothing was ever received.

Speed, without the round trip. A 40 MB PDF does not need to be uploaded and downloaded again. On a slow connection the difference is dramatic, because the transfer, not the processing, is usually the slow part.

No artificial limits. Server capacity costs money, which is why free tiers ration file sizes and daily conversions. Your own processor is already paid for, so the only ceiling is what your device can handle.

It keeps working offline. Once the page has loaded, most client-side tools continue to function without a connection — which is itself a practical way to prove nothing is being sent.

How to check any tool yourself

Do not take this on trust, including from us. Every major browser ships the tools to check.

1. Open the tool's page, then open your browser's developer tools (F12 on Windows and Linux, Option-Command-I on a Mac).
2. Switch to the Network tab and clear it.
3. Process a file as you normally would.
4. Watch the list of requests.

A client-side tool shows requests while the page loads its own code, then nothing when you process the file. A server-side tool shows a large outbound request — usually a POST — roughly the size of your file, at the moment you hit the button. The distinction is unmistakable, and it requires no technical background to see.

The stronger test is to disconnect from the internet after the page loads. If the tool still works, the processing is unambiguously local.

The claim can be enforced, not just stated

Most privacy claims are policy: a sentence on a page saying files are not uploaded. A sentence can be revised, and it cannot be checked.

A Content Security Policy is different. It is an HTTP header, delivered with every page, in which a site declares the only destinations its own code is permitted to contact. The browser — not the site — enforces it. Any request to a destination outside that list is blocked before it leaves your machine, whether it was placed there deliberately, by a compromised dependency, or by accident.

Filevane publishes its full policy, and the reasoning behind each entry, on the privacy proof page. You can read the header yourself: it appears in the Network tab against the page request, under Response Headers. The relevant directive is connect-src, which governs where the page may send data.

This is the difference between "we do not upload your files" and "your browser will not permit this page to upload your files". Only the second is verifiable by a stranger.

Where we do touch the network, and why

A privacy page that claims a clean sweep is less credible than one that names its exceptions, so here are ours in full.

• The contact form submits your message to a form-handling service. That is the entire purpose of a contact form.
• OCR downloads a language-recognition model the first time you use it. The model travels to you; your image does not travel anywhere.
• The currency converter requests published exchange rates. It sends the currency pair you selected and nothing else.

In every case the direction is what matters: reference data comes down to your device, and your documents stay on it. Each of these destinations is named explicitly in the CSP, which is precisely why they cannot be hidden.

The honest limitations

Client-side processing is not universally better, and it is worth knowing where it strains.

Very large files depend on your device. Processing happens in your browser's memory. A 500 MB PDF on a phone with limited RAM may be slow or may fail outright, where a server with 64 GB would not notice. Desktop browsers handle most real documents comfortably, but the constraint is real.

The first load is heavier. Shipping the processing engine to you means downloading it. A server-side tool sends a thin page and does the heavy lifting elsewhere. This is a one-time cost per engine, and it is why the tools feel instant afterwards.

Some work genuinely cannot be done locally. Anything requiring a live external dataset, a licensed engine, or coordination between users needs a server by definition. Where that is true, the honest answer is to say so rather than to pretend otherwise.

Browser support varies. WebAssembly is available in every current browser, but a very old or heavily locked-down installation may not run everything.

What to do with this

For anything you would not be comfortable posting publicly, prefer a tool that processes files in your browser — and prefer one whose claim you can check rather than one that merely asserts it. The Network tab test takes half a minute and works on any site, including this one.

Your documents are yours. The architecture should make that true, not the privacy policy.