Local vs cloud processing: what it means for client work
Most online media tools work the same way: you upload a file, a server processes it, and you download the result. That is a perfectly reasonable architecture for many things. It is a poor fit for media you do not own.
What uploading actually commits you to
When you upload a client's file to a third-party service, several things become true at once:
- You have disclosed that media to a processor your client did not choose and may not have approved.
- Under the GDPR and similar regimes, that processor is now handling personal data on your behalf, which usually requires a data processing agreement.
- The file exists on infrastructure you do not control, subject to retention practices you have to take on trust.
- It may persist in backups and logs long after the visible copy is deleted.
For a personal photo, that is a fine trade. For unreleased campaign work under NDA, it can be a genuine contractual problem.
The local alternative
Some processing genuinely does not need a server. Metadata scrubbing is a good example: it is byte manipulation on a file you already have, and browsers have been able to do that efficiently for years via ArrayBuffer and typed arrays.
When a tool runs the work in your browser tab, the file never crosses the network. There is no processor to name in a DPA, no retention question, and no breach exposure — because there is nothing on the other end to breach.
This is the difference between a privacy policy and a privacy property. A policy is a commitment that can change or be broken. An architecture with no upload endpoint cannot leak what it never receives.
How to verify a claim of local processing
You do not have to take anyone's word for it. Open your browser developer tools, switch to the Network tab, and process a file. Then look at what was sent.
- A genuinely local tool shows no request carrying your file — you will see the page assets load and nothing else.
- Watch for large POST or PUT requests appearing at the moment you hit process. That is your file leaving.
- Check for requests to storage domains, which often indicate a direct-to-bucket upload.
- Enable "Preserve log" first so a page navigation cannot hide the evidence.
This takes about thirty seconds and is worth doing for any tool you are about to put client work through.
Where local processing runs out
It is not a universal answer. Video re-encoding is the clearest limit: browsers cannot transcode video at usable speed, so any tool offering fast video processing is almost certainly doing it server-side. Large-model inference is similar.
The honest position is that local processing is the right default for anything that can be done locally, and that tools should be explicit about where they cross that line.