Are online image tools safe?

Every one of these sites promises your files are safe. You do not have to believe any of them — your browser can show you what actually happened.

Updated 28 August 2026 · 11 min read

You have a file you would rather not hand to a stranger — a scan of a passport, a signed contract, an X-ray, a photograph of your child — and a web page offering to resize it in one click. The question arrives at the worst possible moment, when you are already halfway through the task: is this safe?

The honest answer is that it depends entirely on how the page is built, and that you can find out for yourself in about two minutes without believing a word anybody has written about it. That check is the subject of this article. Everything else here is context for it.

The two architectures

Almost every image tool on the web is built one of two ways, and the difference is not a matter of degree. It decides where your file physically goes.

Server-side. Your browser transmits the file to a computer you do not control, owned by people you have never met, in a country you may not know. Software there opens it, does the work, and sends a result back. For the duration, your image exists on someone else's disk.

Client-side. The page downloads a program into your browser, and that program runs on your own processor, on your own machine, using your own memory. The file is read from your disk by the page and handed back to you as a download. It never crosses the network at all.

Both are legitimate engineering. Server-side processing exists for good reasons: it can run heavy software no browser can, handle formats a browser cannot decode, work identically on a fifteen-year-old machine, and chew through volumes that would exhaust a phone. The point is not that one architecture is virtuous and the other is not. It is that they ask completely different things of you, and most sites do not make it obvious which one you are using.

What “deleted after one hour” actually promises

The standard reassurance on an upload-based tool is that files are deleted automatically after some short interval. Read it carefully. It is a statement of policy — an undertaking about the future conduct of people you cannot observe — and not a technical constraint. Nothing in the architecture enforces it.

Assume the operator is entirely sincere, which most of them are. The promise still rests on a stack of things you cannot see.

Competence. The deletion job has to actually run, on every storage location, including the ones added last spring when capacity ran short. Backups. A snapshot taken twenty minutes into that hour can outlive the deletion by weeks — backups are supposed to survive deletion, that is their entire function. Logs. Even where the file is gone, the record of it may not be: filenames, sizes, IP addresses, timestamps, and sometimes a slice of the data that caused a crash. Subprocessors. Few small sites own hardware; the file may pass through a storage provider, a queue, a delivery network, a monitoring service, each with its own retention and its own promises.

And the clock says nothing about the hour itself. “Deleted after one hour” is silent on what was read or copied during it.

The check: watch what actually leaves your machine

Your browser already keeps a complete record of every byte it sends and receives. It is not hidden, it requires nothing to be installed, and reading it needs no technical background beyond a willingness to look at a list. On a desktop or laptop browser:

1. Open the tool's page and let it finish loading. Do not choose your file yet.
2. Open the developer tools. The keyboard route is F12 on Windows and Linux, or Cmd + Option + I on a Mac; Ctrl + Shift + I also works in most browsers. The menu route is through the browser's main menu, under a grouping named for developers or extra tools — the exact wording differs between browsers and versions, so look for the word “developer” rather than a specific label.
3. Select the Network tab. Every major desktop browser calls it that.
4. If there is an option along the lines of preserve log, switch it on, so that a page reload does not wipe the record.
5. Clear the list, using the clear or bin control in that panel. You now have an empty page of accounts.
6. Do the whole job while watching: choose your file, set the options, press the button, and download the result. Do not stop early — some sites upload the moment you pick a file, others only when you press go.
7. Read the list. You are looking for one thing: a request that carries roughly as many bytes out as your file contains. Note the method column too — uploads are almost always POST or PUT, rarely GET.

If your file was uploaded, it is hard to miss. A 4 MB photograph produces a request measured in megabytes, towering over everything else in the list. Files are sometimes encoded for transport in a way that makes the request about a third larger than the file, and very large uploads are sometimes split into chunks, so add up anything suspiciously big rather than looking for one exact match. If the size column reports what came back rather than what went out, click the request itself; the detail panel shows what the browser sent, under a heading naming the payload or the request body.

If nothing of that scale left — if the list holds only the page, its code, its styling, and perhaps a few requests of a few hundred bytes — the work happened on your computer. Those tiny requests are ordinary analytics or error pings; worth knowing about, but a few hundred bytes cannot contain your photograph.

Two things make the test easier. Use a deliberately large file, because a 4 MB image stands out in the list and a 30 KB one does not. And run it on a file you would not mind losing control of, since the whole point is that you do not yet know what the site does.

What the check cannot tell you

Be precise about the strength of this evidence, because overstating it would be the same error the marketing copy makes.

The network tab tells you what happened on that visit, on that page, with that file. It is a direct observation, which makes it far better than a promise — but an observation of one moment. The site's code can change tomorrow, without announcement, because it is delivered fresh to your browser every time you load the page. A tool may also behave conditionally, processing small files locally and falling back to a server for large ones or for a format its local code cannot decode. That is not sinister; it is a common design. It does mean one clean test with a small JPEG does not license every future upload of a 60 MB scan.

So: if the file genuinely matters, run the check on that occasion, with that file, rather than relying on a test you did three months ago. It costs two minutes, and unlike everything else in this discussion it does not require you to trust anybody.

The tools on this site run in your browser, and the same check applies to them — including this paragraph. Open the network tab, process an image, and see whether anything of that size leaves. The privacy policy describes what is and is not collected in more detail, but a policy is still a document, and the network tab is not.

The second signal: pull the plug

A cruder test takes ten seconds. Load the page, disconnect from the internet — turn off Wi-Fi, or use the offline setting most developer tools panels offer — and try to process a file.

Code that runs on your machine does not need the network to do its work. If the tool completes the job with no connection, nothing was sent anywhere, because there was nowhere to send it. If it hangs, fails, or reports an error, that is a strong hint that something on the other end was doing the work.

The caveat is real, so do not treat a failure as proof. Many client-side tools load their code in pieces, fetching a component the first time you ask for it — the decoder for a particular camera format, say, or the library that assembles a PDF. Ask for that feature while offline and it will fail, not because your file is going up but because the program has not come down. Direction is what separates the two cases, and the network tab shows direction. That is why the offline test is supporting evidence and the network tab is the main witness.

Reading a privacy policy for the parts that mean something

Privacy policies are mostly decorative, but not entirely, and the useful trick is to read them for what they admit rather than for what they reassure.

Phrases that carry information: a statement that processing happens in your browser and files are not transmitted; a named retention period alongside a description of what is retained; third parties and subprocessors listed by name; a specific account of what the analytics collects; a last-updated date recent enough to be believable.

Phrases that carry none: that they take your privacy seriously; that files are handled securely; that the connection uses bank-grade encryption. That last one deserves a moment, because it is the most common confusion in the subject.

One more habit: a policy detailing deletion schedules, storage regions and retention is, in the act of explaining itself, confirming that your file arrives on their systems. That is not a criticism — it may be a very honest policy. It is information, and often clearer than the front page.

How much any of this should worry you

It would be dishonest to pretend every file is a crisis. For a photograph of a beach, a screenshot of a bus timetable, or a picture of a bookshelf you are putting on a listing, this discussion is academic. If it were uploaded and quietly retained forever, the practical consequence to you would be approximately nothing. Use whichever tool is convenient. The one wrinkle even here is location: an ordinary holiday snapshot often carries the exact coordinates where it was taken, worth stripping before you post it publicly whichever tool you use.

The calculation changes for a scan of an identity document; a signed contract, invoice or bank statement; medical imagery or a photograph of a test result; anything relating to a child; anything covered by an obligation you have taken on at work; and photographs taken inside a home, where the background is as informative as the subject.

For those, two minutes with the network tab is a sensible price. Notice too how ordinary the situation usually is: the file is sensitive only because of what is written on it, and you are only there because a form wants it under some arbitrary size limit. Confidential document, mundane task — that combination is exactly where people stop paying attention.

A last piece of proportion in the other direction: no architecture makes you invisible. A tool that never receives your file still receives a request for the page, and its host records the ordinary things any web host records. Client-side processing is a statement about your file, not about your anonymity, and anyone claiming otherwise is overselling it.

Common questions

Isn't HTTPS enough? No, and it is the most widespread misunderstanding here. HTTPS encrypts the journey. The server at the far end decrypts your file on arrival, because it cannot process something it cannot read. Encryption in transit protects you from an eavesdropper on the network, not from the recipient.

Can I run the network check on a phone? Not easily. Mobile browsers generally do not expose the tab. You can connect a phone to a computer and inspect it remotely, but the simpler route is to run the check on a desktop browser — it is the same page and the same code being served to both.

What if a site says it does not upload files, but the check shows an upload? Then you have learned something concrete and should use a different tool. It is not always deception — a site may be describing an intent, or a version of itself that changed. Either way, the observation beats the sentence.

Is an installed desktop application safer than a website? It is a different trade, not automatically a better one. An installed program has far more access to your machine than a web page does, but it does not need to send your file anywhere to work on it. Judge it by the same question: watch whether it contacts the network while it processes a file.

Does clearing my browser data or using a private window help? Not with this. Those affect what is stored on your own device. If a file has been transmitted to a server, deleting your local history has no effect on the copy that arrived.

If the work happens in my browser, can the site still see anything? It can see that someone visited, along with the usual details any web host records. It cannot see the contents of a file that was never sent — but that is a claim about the file specifically, and the network tab is how you confirm it rather than accept it.