You need to compress a PDF containing a client contract, or resize a photograph that has not been published yet. You search, find a free online tool, and upload the file. It works, you download the result, and you close the tab.
Where did that file go? How long does it stay there? Who can read it?
Most people never ask, and for most files it genuinely does not matter. But the answer varies enormously between tools that look identical from the outside, and it is worth understanding the difference — particularly if you handle anything under an NDA, anything with personal data in it, or anything your employer would prefer stayed internal.
Two fundamentally different architectures
Server-side processing
Your file is transmitted to a machine you do not control. That machine processes it and sends a result back.
Between those two moments, your file exists on someone else's hardware. It may be written to disk. It may be picked up by a backup. It may pass through a load balancer, a CDN, or a logging system. None of this is sinister — it is how ordinary infrastructure works — but it means the file's safety depends entirely on choices made by people you will never meet.
Client-side processing
The page loads code into your browser, and that code does the work on your own machine. Your file is read from disk by the browser, processed in memory, and written back out as a download. It never crosses the network.
Modern browsers are genuinely capable here. The File API reads local files, Canvas manipulates images, WebAssembly runs near-native code, and the Web Crypto API performs real cryptography. A decade ago most of this required a server. Today a large proportion of everyday file tasks can happen entirely locally.
The practical consequence: with a client-side tool, there is nothing for a breach to expose, because nothing was ever sent.
How to tell which one you are using
You do not have to take anyone's word for it. Two checks settle it in under a minute.
The network check
Open your browser's developer tools (F12), go to the Network tab, then use the tool.
If your file is being uploaded, you will see a request carrying it — a POST with a payload roughly the size of your file. If processing is local, you will see no such request. Small requests for analytics or usage counting are normal and are not your file; you can tell by the size.
The offline check
This one is decisive. Load the page, then disconnect from the internet, then use the tool.
If it still works, the processing is unambiguously happening on your machine. If it fails, it needed a server.
Where ZeeSharp actually sits — specifically
We think it is more useful to be precise than to make a blanket claim, because a blanket claim would not be true. Different tools work differently, for real technical reasons.
Processed entirely in your browser — nothing is uploaded:
- Image Compressor, Crop & Resize and Convert Image use Canvas to do the work locally.
- Password Generator and Hash Generator never transmit what they produce.
- AES Encryptor uses the browser's built-in Web Crypto API, so your plaintext and passphrase stay on your machine.
- JWT Decoder decodes locally — which matters, because tokens are credentials.
- Text tools such as Word Counter, Text Diff and Readability Score work on text in the page.
These tools contact our server only to count a usage against your plan. That request carries which tool was used, not what you put into it.
Processed on our server, because they have to be:
- PDF operations such as Merge PDF and Compress PDF use processing libraries that do not run in a browser.
- Background Remover needs a model that is impractical to run client-side.
- Anything that inspects the internet on your behalf — DNS lookups, SSL checks, URL fetching — is inherently a server operation, because your browser cannot perform those queries directly.
For the server-side file tools, uploads are written to a temporary directory, processed, and deleted as soon as the request completes — the deletion runs even if processing fails partway. They are not retained, indexed or used for anything else.
A worked example: sharing a secret
One-Time Secret is a useful illustration of a middle path, because it is both.
The secret is encrypted in your browser before anything is sent. Only the ciphertext reaches our server. The decryption key is placed in the URL fragment — the part after the # — and browsers never transmit the fragment to a server. So the link you share contains the key, but our server only ever holds an encrypted blob it cannot read.
That design detail is the whole point. "We do not look at your data" is a promise. "We are not able to" is a property of the system.
When it genuinely matters
Be deliberate about architecture when a file contains:
- Other people's personal data. Under GDPR and similar regimes, sending customer records to a third-party processor without a lawful basis and an agreement in place is your organisation's problem, not the tool's.
- Anything under NDA or client confidentiality. Most agreements do not carve out "but I needed to compress it".
- Credentials. Tokens, keys, certificates, connection strings. Treat any of these pasted into a server-side tool as potentially exposed.
- Unpublished work. Financial results, product designs, manuscripts, anything embargoed.
- Identity documents. Passport and licence scans are prime material for identity fraud.
For a meme you are about to post publicly, none of this matters. Proportionality is reasonable. The mistake is not having a default at all.
Questions worth asking of any online tool
- Does it say where processing happens? Tools that work locally usually say so, because it is a genuine advantage.
- Is there a retention policy, and is it specific? "Files are deleted after one hour" is a commitment. "We take your privacy seriously" is not.
- Does it require an account for a simple operation? Sometimes reasonable, sometimes an indication that the data is the product.
- Is it HTTPS? Non-negotiable. Without it, the file is readable in transit by anyone on the network path.
- Who operates it? A tool with no identifiable operator, no terms and no contact route offers you no recourse.
Habits that cost nothing
- Strip metadata before sharing photographs. EXIF data routinely includes GPS coordinates. A holiday photo is fine; a photo taken at home is a published home address.
- Redact before uploading, not after. And redact by removing content, not by drawing a black rectangle over it — black boxes in PDFs are frequently just a shape on top of text that is still selectable underneath.
- Use sample data when testing. You rarely need a real production record to check whether a converter works.
- Prefer local processing when the choice exists and the outcome is identical. There is no cost to picking the safer option.
The point
This is not an argument that server-side tools are untrustworthy. Plenty are operated responsibly, and some jobs genuinely cannot be done any other way.
It is an argument for knowing which kind you are using. That knowledge takes sixty seconds to acquire with the network tab, and it turns an unexamined habit into a decision — which is all anyone can reasonably ask.