Client-side vs server-side metadata removal

Published 19 August 2026

"Client-side" and "server-side" describe where the actual stripping code runs — not a marketing distinction, an architectural one, and it changes what you have to trust and how you could check it. Here's what actually differs, without assuming either approach is dishonest.

What "server-side" means

A server-side tool works the way most web software has always worked: your file is uploaded to a server you don't control, processed there, and the result is sent back. The processing itself might be entirely legitimate and the metadata genuinely removed — the trust question isn't whether the code does what it claims, it's what happens to your file during the round trip. Does the server log the upload? Cache it? Retain it for debugging, or because a backup ran before deletion? Those are policy questions, answered by a privacy page you have to take on faith, because nothing about the architecture lets you verify the answer yourself. The file left your device — that part is not in question, only what happened to it afterward.

What "client-side" means

A client-side tool runs the stripping code inside your own browser, using JavaScript already downloaded to your machine, and never constructs a request to send your file anywhere. Whether that's actually true is checkable, not just claimed — open your browser's Network tab, use the tool, and watch whether any request fires. This site goes a step further and runs that code inside a frame served with Content-Security-Policy: connect-src 'none', which makes the browser itself refuse any outbound request from that frame regardless of what the code tries — a difference between "observed not to upload" and "structurally cannot upload," covered in detail on how to verify the no-upload claim.

What server-side architectures do better

This isn't a one-sided comparison. A server can bring far more processing power to bear than a phone's browser can, which matters for large batch jobs or formats that need heavy computation to parse safely. It can also support formats or edge cases that would be impractical to implement correctly in JavaScript running in a sandbox. And a server-side tool can update its parsing logic centrally the moment a new vendor metadata format shows up, without waiting for every user to reload a page. Client-side processing trades some of that capability for a verification property server-side processing structurally cannot offer: there is no server in the loop for your file to reach, so there's nothing to log, retain, or breach on the processing side.

The tell: does the tool need an internet connection to work?

The fastest practical check, no DevTools required: turn off your wifi and reload the page. A genuinely client-side tool keeps working, because it never depended on a server for the file-processing step in the first place — only the initial page load needed a connection. A server-side tool fails immediately, because the round trip its architecture depends on has nowhere to go. This site is built to pass that test, and it costs nothing to try.

Neither architecture is inherently more honest

A server-side tool can have an excellent privacy policy, delete uploads immediately, and mean every word of it. A client-side tool can still load third-party analytics or advertising scripts that see unrelated data about you, even while the file itself never leaves the device — worth checking on any client-side tool you use, this one included, since what runs where is exactly the kind of thing a privacy page should be specific about rather than vague. The architecture changes what's verifiable, not automatically what's true — which is precisely why "verifiable" is the property worth optimizing for, rather than trusting either label on its own.

Try it

Drop a file into any tool on this site with your Network tab open, or read the full step-by-step verification guide — the same method works on any tool making a client-side claim, not just this one.