You have a signed contract to compress, or an ID scan to convert, or a photo whose GPS coordinates should not travel with it. You search for a free tool, find one, and drop the file in. Somewhere between the drop and the download, one of two very different things happened — and the page almost certainly did not tell you which.
Two architectures, one interface
Nearly every free online tool falls into one of two designs that look identical from the outside.
Server-side: your file is uploaded, processed on someone else's machine, and the result is sent back. This is how most free converters work, and it is a perfectly reasonable engineering choice — server-side tools can do things browsers cannot. But your file now exists on infrastructure you do not control, and what happens to it next is governed by a privacy policy rather than by physics.
Client-side: the page loads code that runs in your browser, and the file is processed on your own machine. Nothing is transmitted. There is no copy to retain, log, or lose.
The reason this distinction is worth caring about is not that server-side operators are untrustworthy. It is that trust is unnecessary in the second case.
How can I tell whether an online tool uploads my file?
Open your browser's developer tools, switch to the Network tab, and run the tool on a file. If processing is local you will see no request carrying the file's bytes. A second test: disconnect from the internet after the page loads. A genuinely client-side tool keeps working; an uploader immediately fails.
The offline test is the one to remember, because it needs no technical knowledge and cannot really be faked. Load the page, turn off Wi-Fi, use the tool. It either works or it does not, and the answer is unambiguous.
What browsers can actually do now
Client-side tools stopped being toys because the platform underneath them grew up. The APIs doing the work are ordinary parts of the web now:
- Canvas — decode, resize, crop and re-encode images.
- Web Crypto (
crypto.subtle) — AES-GCM encryption, PBKDF2 key derivation, SHA hashing, RSA and EC keypairs, all native and constant-time. - WebAssembly — compiled C and C++ libraries running at close to native speed. This is how HEIC decoding and PDF encryption work in a tab.
- MediaRecorder and Web Audio — screen recording, microphone capture, waveform editing.
- File System Access — read and write local files directly, without a round trip.
Ten years ago a browser could not decode a HEIC or AES-encrypt a PDF. Today both are unremarkable.
Why client-side tools have no file size limits
Server-based tools cap file size because every upload costs the operator bandwidth and processing time, which is what the paid tier exists to fund. A tool running in your browser spends your device's memory instead, so the practical ceiling is your own available RAM rather than a business decision.
This also explains the other familiar limits — daily conversion caps, queues at busy times, watermarks on the free tier. Each is a way of rationing a cost that a client-side tool never incurs. Nothing generous is going on; the expense simply is not there.
Where it matters most
Documents with legal or financial content
Contracts, invoices, tax records, medical letters. Compress or merge these locally with the PDF Compressor and PDF Merger; both use pdf-lib in the page. Password-protecting a PDF is a particularly clear case — the PDF Protect tool runs qpdf compiled to WebAssembly, so the document and its password stay on your machine. Uploading a file and its password to a third party rather defeats the purpose of encrypting it.
Photos with location data
Phone photos carry EXIF metadata including GPS coordinates, device identifiers and timestamps. The EXIF Viewer & Remover shows exactly what is embedded and strips it by rewriting the file container — not by re-encoding, so the image itself is untouched. Worth doing before posting anything taken at home.
iPhone photos that will not open
HEIC is an Apple default that most of the rest of the world cannot read. The HEIC to JPG Converter decodes it with a WebAssembly build of libheif and re-encodes as JPG or PNG, in bulk, with no per-day cap — the photos never leave the device, which matters because camera rolls are personal by definition.
Secrets
API tokens, JWTs, password hashes. A JWT decoder that posts your token to a server has just handed someone a live credential. The AES encryption tool derives its key with PBKDF2 in the page; the passphrase never becomes network traffic.
The honest limitations
Client-side is not universally better, and pretending otherwise would be its own kind of marketing.
- Very large files can exhaust memory. A browser tab has less headroom than a server. A multi-gigabyte video may simply fail where a server-side service would succeed.
- Some formats are genuinely unavailable. Browsers cannot encode AVIF via canvas, for instance — and worse,
toBlobsilently returns a PNG when asked for one, so a tool built on it would hand you files with the wrong contents. We dropped a planned AVIF converter for exactly this reason rather than ship a lie about the output. - Heavy work is bounded by your hardware. Video encoding on an old laptop is slow, and no amount of good architecture fixes that.
- The first load is larger. WebAssembly modules have to arrive before anything can run.
For documents, images, text and audio, none of these bite. For heavy video, server-side still has a real advantage.
Do these tools work offline?
Once the page has finished loading, yes. The code is already in the browser at that point, so the work happens with no further network access. Disconnecting mid-session is in fact the simplest way to prove a tool is doing what it claims.
Frequently Asked Questions
Is "we delete your files after an hour" good enough?
It is a promise about deletion, not a limit on what happened while the file was there. Whether it was logged, cached by a CDN, backed up, or copied is outside what that sentence covers. A file that was never sent has none of these questions attached to it.
Why do so few free tools work this way?
Client-side is harder to build and harder to monetise. There is no upload to gate behind a sign-up, no processing queue to sell priority in, and no server-side view of what users are doing. The engineering is also genuinely more constrained — everything has to fit and run in a browser tab.
Can I trust a site that says "no upload"?
Verify it rather than trusting it, which takes about a minute. Network tab, or the offline test. Any tool making the claim should survive both, and the ability to check is the entire point of the architecture.
Every tool on this site runs in your browser. Try the offline test on any of them — PDF, image, security — and watch them keep working with the network off.