Verification guide

Does a watermark remover upload your image?

Most do. You can prove it either way in about a minute without trusting any privacy claim: load the tool, switch the browser offline, then run a removal. If the cleanup finishes with no connection, the image was processed on your device. If it stalls or returns an error, the image had to leave it.

The 60-second test

1. Load the page normally. Keep the tab open. Do not refresh it after this point, because a refresh may need the network again.
2. Pick a large file. Use an image of several megabytes. A big file makes any outbound copy obvious, because ordinary analytics requests are tiny.
3. Go offline. In Chrome or Edge, open DevTools, select the Network tab, and set throttling to Offline. In Firefox, use the Network throttling menu. On any browser you can also turn off Wi-Fi or enable airplane mode.
4. Run the removal. Choose the image, mark the watermark, and start the cleanup.
5. Read the result. A finished preview and a working download button mean the work happened locally. A spinner that never ends, an "upload failed" message, or a blank result means the tool needed a server.

This test is decisive because of what it removes from the equation: marketing language, terms of service, and promises about deletion. A tool cannot send your file anywhere if the browser has no route out.

Two honest caveats before you trust the result

Run the test twice on tools that fail the first time. Some browser-based editors download a machine-learning model the first time you press the button. Offline, that download cannot happen, so the tool fails even though the actual repair would have run on your device. Load the tool once while online, complete one edit, then repeat the offline run.

Also confirm the failure is really about the network. If a tool fails offline with a message about a session, a captcha, or a queue position, that is still evidence that a server is involved in the edit.

What an upload looks like in the Network panel

The offline test tells you yes or no. The Network panel tells you where the file went. Before you start, tick Preserve log so the list is not cleared, then run the tool while online and look for these signals:

• A POST or PUT request that appears exactly when you press the button. Filter the panel with method:POST to cut the list down to requests that carry a body.
• A request body that matches your file size. Select the request and open the Payload tab. An image upload shows binary or multipart form data whose size is close to the source file. Also check the request headers for Content-Length.
• A destination you do not recognise. Sort by domain, or filter with domain:. A file leaving for an inference API or a storage bucket usually goes to a host that is not the site you visited.
• A separate download for the finished image. Server-side tools upload your file, then return a URL or a second response containing the cleaned result.

One console command gives you the same answer without reading the panel line by line. After running the tool, paste this into the console:

performance.getEntriesByType('resource').filter(r => r.initiatorType === 'fetch' || r.initiatorType === 'xmlhttprequest').map(r => r.name)

Anything listed was requested by script while the page was open. A locally processing tool shows no entry tied to the moment you pressed the button.

Three network requests that are not an image upload

Do not panic at every request in the list. These three are common on tools that still process locally:

• Analytics and telemetry. Small POST requests of a few kilobytes, usually to a known analytics host. Their size is nowhere near your image.
• Model weights. A one-time download of several megabytes of data coming into the browser. Watch the direction: data arriving is a download, data leaving at the size of your file is an upload.
• Fonts, stylesheets, and scripts. Normal page assets, present the moment the page loads and long before you choose an image.

The test that separates them from an upload is size and timing. An upload is roughly as large as your image and fires when you start the edit.

The code-level check: read the JavaScript

If you want evidence that does not depend on catching a request at the right moment, read what the page is allowed to do. Open DevTools, go to Sources, and search the site's scripts for the browser APIs that can move data off the device: fetch(, XMLHttpRequest, navigator.sendBeacon(, and WebSocket.

None of these prove an upload on their own, because they are also used for analytics and for loading assets. What matters is whether any call sends the selected file or its pixel data. If you find none of them at all, there is no path for the image to travel.

A second, stronger signal is the response header content-security-policy. If a page declares connect-src 'none', the browser blocks every script-initiated network request on that page, which makes an upload impossible regardless of what the code tries to do.

What local processing actually looks like

Tools that genuinely work in the browser follow the same shape. The file is read with the File API or turned into a local blob: URL, decoded into an Image, and drawn onto a <canvas>. The repair reads pixels with getImageData, writes them back with putImageData, and the download is produced by canvas.toBlob(). Every step names a browser API that operates on memory in your own tab.

On this site, that is what happens. The scripts behind the watermark remover, the text removal page, and the logo removal page contain no fetch(, XMLHttpRequest, sendBeacon, or WebSocket call, so there is no code path that transmits the image. The file is opened with URL.createObjectURL(file), decoded into an Image, drawn to a canvas, and written out through canvas.toBlob(). You can confirm all of this yourself in the Sources tab.

Two further details are readable in the source and worth knowing, because they are the practical cost of keeping everything on your device:

• Large images are scaled down before editing. The home page caps the editing canvas at 1800 px on the longest side and the logo page at 2400 px. A phone camera photo is well inside that; a large scan may be reduced before the repair begins.
• Decoding is done by your browser, not by this site. That is why formats such as HEIC and HEIF open on some devices and not others. The browser either has a local decoder or it does not, and no server is available to fall back on.

The trade is straightforward. Local processing means a confidential screenshot never reaches anyone else's disk, and it also means the tool is limited by your device's memory, decoder support, and patience. Cloud processing buys more computing power and pays for it with the upload.

What the privacy policy can and cannot tell you

Policy text is the weakest evidence, but it is still worth one check. Look for a stated retention period and a statement about where processing happens. Vague wording such as "processed securely" without a location, or a retention clause that says images are kept for a period before deletion, points to server-side handling. A page that processes locally can say so in concrete terms, because the claim is testable with the steps above.

MarkVanish describes its handling on the privacy page, and the offline test above is the way to check that description rather than take it on faith.