“No upload” is a security feature, not a privacy slogan
There is a line in the marketing copy of almost every free online tool: we respect your privacy, we never store your files, we take your security seriously. Those sentences are unfalsifiable. A policy document states what an operator intends to do; it cannot show you what the code actually does. And since these promises are also used by services that do keep your files, treating one as evidence has stopped being reasonable.
There is a different kind of claim, and it is worth learning to tell them apart. It is architectural rather than promissory. Instead of promising restraint, it removes the possibility. That distinction is the whole subject of this article.
What uploading actually creates
When you drop a photo into a server-side tool, a copy of that photo now exists in someone else's infrastructure. It is worth being precise about what that does and does not mean, because the common reaction is to panic about a dramatic leak, and that is not the risk that matters.
The risk is not usually that your photo becomes public. It is that a copy exists somewhere you do not control, and from that moment its fate is governed by factors entirely outside your reach:
- Retention. Is the upload kept for an hour, a day, or a year? You do not know, and it may not be the operator who knows.
- Backups and derived copies. Storage systems replicate. The one copy you were never told about is the one that surfaces years later.
- Legally compelled disclosure. Data held on someone else's server can be produced in response to a request. Data that never left your laptop cannot.
- Change of ownership. A small tool is acquired. An acquisition carries an obligation to use the data for new purposes, and historical consent rarely covers what comes next.
- Silent policy change. The version of the privacy policy you agreed to when you uploaded may not be the version in force when you find out it was kept.
None of these require anyone to be careless or malicious. They are the ordinary consequences of putting data in someone else's building. That is the point: the exposure comes from the architecture, not from character.
What browser-side processing does instead
When an image is decoded, redrawn and re-encoded on a canvas element in your own browser tab, the only place it exists is your device's memory. There is no request to intercept, no server to breach, no storage bucket with a retention setting, and no operator who could be asked to hand anything over.
This is categorically stronger than a promise, for a reason that is easy to miss: it is not a promise at all. Nobody is restraining themselves. There is simply nothing there to restrain. The guarantee does not depend on any company's continued good intentions.
Where the difference genuinely matters
For a photograph of a sunset you took on holiday, this is largely a philosophical preference. Both outcomes are fine and the difference costs you nothing either way. There is no reason to care much, and pretending otherwise would be dishonest marketing.
For certain files the distinction is the entire question:
| File | Why the exposure is real |
|---|---|
| Passport and ID scans | A biometric document that follows you through every application for a decade |
| Medical images and records | Special-category personal data under most privacy regimes |
| Signed contracts and financial documents | Signature and account imagery is exactly what fraud attempts need |
| Client and agency work | Unreleased assets on a third-party server is a contractual problem before it is a technical one |
| Unpublished creative work | Embargoed launches, unreleased designs, anything you have not announced yet |
The common thread is not secrecy. It is that these are files someone else has a legal or commercial interest in obtaining, or files whose exposure would follow you around for years rather than being forgotten by a feed.
And the metadata nobody thinks about
A separate, quieter leak happens even when everything is done in good faith. Photographs carry EXIF data by default: the model of camera, the exact moment, and — on most phones — the GPS coordinates of where you stood when you took it.
So a photo of a living room can carry its own coordinates, and a photo taken at home can carry the coordinates of your home. Re-encoding to JPG or WebP strips this as a side effect of the conversion, because the new file is built fresh rather than copied. That is why the metadata guide matters even for people who never think about privacy: it is a default in the file format, not an intention. We explain the details there.
How to check this claim yourself, in ten seconds
You do not have to take anyone's word for it, including ours. There are two checks, and the second is the more convincing one.
Look at the network panel. Open your browser's developer tools, switch to the Network tab, drop a file into any tool, and watch. If a request carrying your image's bytes heads for a different domain, it uploaded. This is not a grey area and it is not an inference.
Turn the internet off. Disconnect from Wi-Fi, or enable your browser's offline mode, and try the tool again. If it still works, the processing was happening on your machine the entire time. This is the stronger test because it removes the possibility of a clever fallback. You can run it right now on any page of this site.
That second test is the honest summary of the difference. Architecture you can verify beats a promise you have to trust.
Where browser-side processing is the wrong answer
Being straight about this matters more than the argument for our own approach, because the honest answer is that local processing loses on some things:
- Formats a browser cannot produce. Canvas can decode a very wide range of formats but can only encode JPG, PNG and WebP. There is no AVIF or JPEG XL output without shipping a large codec bundle. That is a genuine limitation, not an oversight, and it is why the converter offers three formats rather than six.
- Scale. A browser tab has a memory ceiling, so hundreds of files in one go is a bad idea. See what actually happens when you compress a hundred photos.
- Convenience you have to earn. An uploaded tool can process on a fast server; your machine may be a five-year-old laptop on a hotel connection.
- Sharing the result. Cloud tools can email you a finished file. Local processing means you save it yourself, which is a small friction and occasionally an annoyance.
For a holiday photo and a slow connection, an uploading service may genuinely serve you better. It is a trade-off rather than a victory lap, and it is one we made deliberately — the reasoning, including what it cost us, is in why we built the tools this way.
Frequently asked questions
How can I tell whether a tool uploads my file or not?
Open your browser's developer tools, go to the Network panel, then drop a file into the tool. If you see a request carrying your image's bytes heading to another domain, it uploaded. You can also disconnect from the internet entirely and try again: a tool that still works was processing locally all along.
Does uploading a photo actually put it at risk?
The file itself is usually not publicly visible, but it does create a copy in someone else's infrastructure, and that copy is subject to their storage practices, their retention settings, their legal obligations and any future change of ownership. The risk is not that your photo appears on the internet; it is that a copy exists somewhere you do not control.
Is a privacy policy enough to settle the question?
No. A policy states what an operator intends to do with data. It cannot prove what the code actually does, and policies change with ownership and business pressure. The architectural answer is stronger: if there is no upload endpoint, there is nothing to go wrong.
Which files should never be uploaded to a free web tool?
Passport and ID document scans, medical images and records, signed contracts and financial documents, and any client asset you are contractually obliged to keep confidential. These are exactly the files where an ordinary holiday snapshot is the wrong mental model.