Skip to content
EveryImage

2026-07-30 · 4 min read

What you agree to when you upload images to a free tool

What is actually in an image file, what upload-based services can do with it, what their terms typically say, and when local processing is the only defensible option.

Most free online image tools work the same way: your files go to a server, are processed there, and come back. It is a sensible engineering choice and it is invisible to the user. It also means that for a period you do not control, your photographs exist on hardware belonging to someone you have never met, under terms you did not read.

That is sometimes fine. It is sometimes a serious problem. The difference is worth being able to reason about rather than guess at.

What is actually in the file

A photograph is not only pixels. A JPEG straight from a camera or phone typically carries:

  • GPS coordinates, often to within a few metres, if location services were on
  • Timestamp, to the second
  • Camera make, model and serial number — the serial is the interesting one, because it links files across shoots
  • Lens, exposure settings, and often a thumbnail of the original frame, which survives some crops
  • Software history, sometimes including the name of the computer or account

For a product photograph this is uninteresting. For a photograph taken at someone's home, it is their address. For a set of images from a photographer's card, it is a linkable identity across every job they have shot.

Stripping this before sharing is good practice regardless of how you process. Any tool that re-encodes through a canvas removes it as a side effect — but the file you uploaded still had it, and that upload already happened.

What the terms usually say

Free services need a licence to operate on your files at all: storing, copying and transmitting an image are things copyright law otherwise reserves to you. So the terms grant one, and the grant is typically broad — worldwide, royalty-free, sublicensable — because the service's lawyers wrote it to cover CDNs, subprocessors and backups.

Most operators genuinely intend nothing beyond processing. But the licence usually outlives that intent, and it is the licence, not the intent, that survives an acquisition, a pivot, or a change of ownership.

Retention is the other clause worth finding. "Files are deleted after one hour" is a policy, and policies apply to the primary store. Backups, logs, error-capture systems and CDN caches are frequently outside its scope, not through bad faith but because nobody wrote that part of the sentence.

Breaches do not require malice

The strongest argument against uploading is not that a service will misuse your files. It is that a service can be compromised, and misconfigured storage buckets have exposed image archives repeatedly and unremarkably for a decade.

A service that never receives your files cannot leak them. This is the security property that matters, and it is structural rather than a promise.

Where it becomes a professional problem

For some categories, uploading is not a preference but a compliance question.

Client work under NDA. If your contract says images will not be shared with third parties, uploading them to a processing service is sharing them with a third party. The fact that it was convenient is not a defence.

Photographs of children. Schools, sports clubs and family photographers routinely handle images where parental consent covers a specific use. That consent did not include a processing vendor.

Anything regulated. Medical imaging, legal evidence, insurance documentation, identity documents. These carry statutory obligations that a free web tool's terms will not satisfy.

Unreleased commercial work. Product photography before a launch, campaign assets under embargo. The risk here is commercial rather than legal, and it is not hypothetical.

What local processing does and does not solve

It solves transmission. If files are read from disk, transformed in your browser, and written back by you, there is no upload, no retention question, no third-party licence and no breach surface.

You can verify it rather than trust it: open your browser's network panel and process a batch. Requests carrying image data will be absent, and that is a stronger assurance than any policy document.

It does not solve everything, and pretending otherwise would be its own kind of dishonesty:

  • The site itself is still served over the network, and if analytics are enabled, page views are still recorded. Look for whether image data is included — in a properly built tool it is not, because it is never sent.
  • Your device is still your device. Malware on the machine sees the files regardless.
  • What you do next is unchanged. Processing locally and then uploading to a social platform means the platform has the images, under its terms.
  • Metadata is only stripped because re-encoding discards it. That is a side effect worth knowing about rather than a security feature.

A workable rule

For anything that is already public or that you are about to publish, an upload-based tool is a reasonable convenience.

For anything covered by a contract, a consent form, a regulation, or an embargo — and for anything containing people who did not agree to it — the file should not leave your machine. In those cases local processing is not a preference. It is the only option that survives being asked about afterwards.