Architecture

Local vs cloud watermark remover: what leaves your device

A browser-based remover sends no image data anywhere; a server-based one sends the entire file. We measured the difference rather than guessing at it. We built the exact multipart request a browser would POST to a server-side tool, in memory, and compared it with the original: identical, byte for byte, plus 378 bytes of form wrapping. Then we injected a marker into a real EXIF segment and watched it survive into that request while disappearing from every locally produced output. Then we timed the local path, five runs per row, and did the transfer arithmetic explicitly so you can see which numbers are measured and which are division.

Measurements come from headless Chrome 154 on Windows, October 1, 2026, on synthetic scenes built from fixed seeds. No file was uploaded and no image left the machine; upload bodies were constructed in memory and never sent. Competitor pages were retrieved the same day (668,662 bytes across three sites). Uplink throughput was not measured — every transfer figure on this page is division at a stated rate, and is labelled as such. Scope and limits are stated at the bottom.

The answer, first

1. Local sends nothing. Cloud sends everything. A 12 megapixel JPEG at quality 0.92 is 4,002,874 bytes. The request body that carries it measures 4,003,252 bytes — the same bytes, verified identical element by element, plus 378 bytes of multipart headers. That 378 bytes is constant across every file size we tried, so on a 2 megapixel file it is 0.058 percent of the body and on a 12 megapixel one it is 0.009 percent.
2. The upload is the file, not the picture. Whatever your file carries rides along: we put a marker string into a real EXIF ImageDescription segment, confirmed it was in the file, and found it in the upload body. The local output contained no trace of it in any of the three formats we saved.
3. Local is not the slow option. Our measured local path for that 12 megapixel file runs 254 to 825 milliseconds depending on output format. Uploading the same file is 32.0 megabits of traffic before any queue, processing, or download of the result — 6.4 seconds at an assumed 5 Mbit/s uplink, 1.6 at 20, 0.32 at 100.
4. The ceilings are different in kind, not just in number. Local tools hit a pixel ceiling: our own engines cap the longest edge at 1800 pixels on the watermark remover and the text removal page, and 2400 on the logo removal page. Server tools tend to publish a byte ceiling: the one competitor that states a limit on its landing page quotes 10 MB, seven times, in file size rather than resolution.
5. Recourse is asymmetric. If no copy was made, there is nothing to ask anyone to delete. If a copy was made on someone else’s machine, what happens to it depends on a policy we cannot read from the outside — and none of the three pages we retrieved mentions deletion or retention anywhere in its text.

What crosses the network, measured

We built three synthetic photo-like scenes at fixed seeds — smooth gradient, soft blobs, per-pixel grain — and encoded each as JPEG quality 0.92. That is the file you would hand to any online tool. For each one we constructed the multipart body a browser would send, then located the file part inside it and compared it with the original array element by element.

Two things fall out of that table. First, the overhead is a fixed 378 bytes, so wrapping cost is irrelevant at any real file size — what you pay for is the file. Second, the decoded pixel array is twelve times the JPEG: 48,000,000 bytes against 4,002,874. That gap is why a local tool has to think about memory at all, and why the first thing it does with a large image is usually to make it smaller.

What rides along inside the file

“It only uploads the image” is not reassuring if the image is not only pixels. We took the 4 MP file, inserted a standards-shaped APP1 EXIF segment holding one ImageDescription string of our own marker text, and verified the marker was really in the file before doing anything else — the segment added 59 bytes to a 1,290,009-byte file.

The upload path carries the metadata because it carries the file; there is no step in it that separates the two. The local path drops it before any editing happens, at the decode boundary, which is also what we found when we measured metadata across a full round trip. If you want the metadata gone, that part is easy and does not require a watermark tool at all. If you want it preserved, check whether the tool you are about to use is the kind that keeps it.

Batch multiplies it exactly

Server-side tools market batch processing, and batch is where the byte count stops being theoretical. We built bodies carrying 1, 5, and 10 copies of the same 2 MP file. Egress is linear: nothing about a second file makes the first one cheaper.

Speed: the part we measured, and the part we divided

We do not have an uplink measurement for this machine, so we are not going to publish one. What we do have is the local path, timed five times per row with the median reported and the range shown alongside, because the machine was running other work and the first decode of a large image is genuinely variable.

Read the 12 MP row at the 1800 cap as the honest headline: 302 milliseconds to decode, 3 to resize, 58 to write JPEG — under half a second on a mid-range machine for the whole local path. Note also that WebP encoding costs an order of magnitude more than JPEG at every size; if a tool feels slow and lets you pick the output, that is usually why.

Every figure in that second table is bytes times eight, divided by a rate we picked. It excludes connection setup, anything the server does before it starts reading, the server’s own processing, and the download of the result back to you — all of which are real and none of which we measured. It is here to give the upload a scale, not to predict your wait.

Two different ceilings, measured differently

This is the part most comparisons get wrong, because the two architectures cannot be capped in the same units.

A local tool runs inside your browser, so its limit is what the browser and the device will hold. Our own engines cap the longest edge: 1800 pixels in the engine shared by the home tool and the text removal page, and 2400 pixels in the separate engine on the logo removal page. On a 12 megapixel input that is a reduction to 20.3 percent and 36.0 percent of the original pixels respectively. The home page copy states no number; the numbers come from the code, and they are per page, not site-wide.

A server-side tool’s limit is usually stated in bytes, because bytes are what cross its network. The one competitor that publishes a limit on the page we retrieved repeats “10 MB” seven times. Note what that does and does not tell you: a byte ceiling says nothing about resolution, and a pixel ceiling says nothing about file size, which is why a 12 megapixel JPEG at 4.0 MB can pass a 10 MB gate while a noisy image one third the size might not. We wrote about that mismatch, and about how to get a file under a byte limit yourself, on the file size page.

On the question of which architecture produces a better repair, we are not going to answer from these numbers. Repair quality depends on the algorithm on either side, and we have only measured one side. What you can do is check the result yourself, which we covered on the quality page.

What the tools tell you about themselves

On October 1, 2026 we retrieved the landing pages of three watermark removal services and counted, in the visible page text, how they describe where the work happens. Scripts and styles were stripped before counting.

Read that as what it is: a count of strings in one page of HTML, on one day. It is not evidence about anyone’s architecture, and we did not read these services’ privacy policies for this measurement. What it does show is that a reader arriving at these pages cannot tell, from the page, whether a copy of their file will exist somewhere else afterwards — and that is exactly the question this page exists to answer with numbers instead of adjectives.

Recourse, which only one side can offer

The difference that matters most is not speed or sharpness. It is what you can still do afterwards.

• With a local tool there is no copy. Nothing to request, nothing to delete, nothing to hope for. The image was in your browser’s memory and then it was not. The flip side is real too: there is no history, no undo after you close the tab, and no recovery if you lose the download. We measured what that actually means in practice on the no-signup page.
• With a server tool there is a copy, by construction. It has to exist for the work to happen. Whether it is deleted, and when, is governed by a policy you would have to read. We did not read those policies, so we are not going to characterise them.
• Both sides can be wrong about themselves. A page can say “in your browser” and still send the file; a page can say nothing and still be entirely local. Claims are not the test. The test takes about a minute: load the page, switch the browser offline without reloading, then run a removal. The full method, including what to look for in the Network panel and how to read the JavaScript, is on our verification page.

Which one to use

Frequently asked questions

Does a cloud remover get the whole file or just the marked region?

The whole file. In our measurement the file part of the request body was identical to the original at every size we tried, with a constant 378 bytes of multipart wrapping added. Nothing in a standard form upload crops before sending.

Is local processing always slower?

Not in our measurements. The 12 MP path took 254 to 825 milliseconds depending on output, before any upload, queue, or download. Where a server wins is not wall-clock on a single image; it is having hardware you do not have.

Will uploading strip my metadata?

No — uploading cannot strip anything, because the file goes as it is. Our marker was present in the upload body and absent from all three locally produced outputs. Metadata is dropped at the decode boundary, which happens before any removal step.

Do I have to choose between privacy and quality?

We cannot answer that from measurement, and we are not going to assert it. The measurable trade-off on our side is resolution: the local caps reduce a 12 MP input to 20.3 or 36.0 percent of its pixels. Whether that matters depends on what you are doing with the result.

How do I check a tool I have never used?

Load it, go offline without reloading, and run a removal. If it finishes, it was local. If it hangs or errors, the file had to leave. The longer version, with the Network panel and the JavaScript check, is on the verification page.

Does a local tool still need the internet?

To load the page, yes. After the scripts are in the browser, the editing itself makes no request, which is why the offline test is decisive.

Scope and limits

• Everything measured here ran in headless Chrome 154 on Windows on October 1, 2026, on synthetic scenes built from fixed seeds: gradient, soft blobs, and per-pixel grain. They are not photographs of real subjects, and their byte counts will not match your camera’s output.
• No image was uploaded. Upload bodies were constructed with FormData and Request and measured in memory; the request was never sent. The 378-byte overhead is specific to that construction and would differ with different field names or an extra field.
• Uplink throughput was not measured. We tried a public speed-test endpoint and got an empty response, so every transfer figure here is bytes divided by a rate we chose, and it excludes connection setup, server processing, and the download of the result.
• Timings are medians of five runs on a machine that was running other work. Decode is the noisiest figure — the range is shown for every row because it is wide.
• We tested canvas allocation at 4096 and 8192 pixels per side, both of which succeeded; we did not push to the browser’s documented maximum, because doing so would have allocated a gigabyte on a 4 GB machine. The device ceiling is real and we did not find its edge.
• The local caps quoted are from our own source: 1800 on the longest edge in the engine shared by the home and text pages, 2400 in the engine on the logo page. They are per page, not site-wide, and the home page copy states no figure.
• Competitor counts come from landing pages retrieved on October 1, 2026 and will change. They were counted after stripping scripts and styles, on visible text, and we did not read those services’ privacy policies. A missing string on a landing page is not a claim about anyone’s architecture.
• We make no claim about the repair quality of any service other than our own, and no claim about anyone’s data retention.