How server-side image tools work
Most online image converters, compressors, and editors work by uploading your file to a web server. Your browser sends the image as an HTTP POST request. The server receives the file, processes it using server-side software, writes the result to a temporary location, and sends it back to your browser for download.
Even if the server deletes the file after delivery, the transit itself creates several points where the data can be retained:
- Web server logs: Many frameworks log request bodies by default. Your upload can appear in application logs stored on disk or in a cloud logging service.
- Error tracking: If processing fails, tools like Sentry or Bugsnag may capture the request payload including your image data for debugging purposes.
- Temporary file storage: The server writes your image to disk or object storage. Even "immediately deleted" files can persist in backups or trash before the deletion is finalized.
- CDN caches: If the tool uses a content delivery network, processed output may be cached at edge nodes for a period after delivery.
- Analytics: Third-party analytics scripts embedded in the page can observe HTTP transactions and input events.
What a photo can contain
A photo is not just pixels. An iPhone photo carries EXIF metadata including GPS coordinates, capture time, and camera model. A photo you take at home, at work, at a hospital, or at a private event carries the location of that place embedded in the file. When you upload such a photo to a server-side tool, you are sharing that metadata along with the image content.
Beyond metadata, the visible image may show faces, documents, license plates, screens with notifications, financial information, or locations. A photo is often more sensitive than it appears at a glance.
Platform privacy policies: what they usually say
Most online image tools include a privacy policy that says something like "we do not store your images after processing" or "files are deleted after one hour." These statements are usually honest, but they apply to intentional storage. They do not cover incidental retention in logs, error tracking systems, or infrastructure backups controlled by cloud providers. The operator may not be storing your file deliberately, but copies can persist in systems they do not fully control.
Privacy policies also do not create legal obligations enforceable by you unless you have a formal agreement with the provider. For truly sensitive content, a policy is a weaker protection than a tool that never receives the file.
How browser-native tools work differently
Modern browsers run JavaScript that can perform complex image operations — decoding, re-encoding, compressing, resizing, stripping metadata — entirely within the browser's rendering engine without sending any data to a server.
When you use a browser-native image tool, the file never leaves your device. It cannot be logged or cached by a server because it was never transmitted. The sequence is:
- You select the file. The browser reads it into memory locally.
- JavaScript processes the image data in the same tab — decoding pixels, applying transforms, re-encoding.
- The output is written to a Blob in memory and offered as a download link.
- No HTTP request carries your image data outbound.
Server-based vs browser-based, side by side
The difference comes down to where the work happens — and whether your file ever leaves your device.
| Aspect | Server-based tool | Browser-based tool |
|---|---|---|
| Where it runs | A remote server | Your own device |
| Is the file uploaded? | Yes, over the network | No, it never leaves |
| Retention risk | Logs, caches, backups | None |
| Works offline? | No | Yes, after the page loads |
| Best for | Public, low-risk photos | Private documents, IDs, faces |
How to verify that a tool is actually local
Claims of "client-side processing" are common and not always accurate. The only reliable verification is your browser's Network panel. A genuinely local tool shows no outbound POST carrying image data; you may see requests for static assets (HTML, CSS, JavaScript files loaded once) or anonymized analytics pings, but none of those contain your image. To check:
- Open DevTools with F12 or Cmd+Option+I.
- Go to the Network tab. Enable Preserve log.
- Drop your image into the tool and trigger the operation.
- Filter by XHR/Fetch. If any outbound request carries your image as a payload, the tool is server-side.
When server-based tools are acceptable
Not every photo requires the same level of caution. Product photos for a public online store, stock images, or landscape photos taken in public places carry minimal risk when uploaded to a reputable tool. The privacy question is most relevant for:
- Photos taken at home, work, school, or other private locations (GPS in EXIF)
- Photos of people who have not consented to their image being shared with a third party
- Photos of documents, ID cards, financial statements, or medical information
- Photos that reveal information about unpublished products, private spaces, or confidential contexts
What PhotoTools does
Every tool on PhotoTools — image conversion, compression, resizing, cropping, EXIF removal, watermarking, and passport photo layout — runs entirely in your browser. The processing code is JavaScript that executes locally in your tab. No image data is sent to any server. You can verify this in the Network panel: there are no outbound POST requests carrying image payloads.
The site loads static assets once from a CDN. After the initial page load, it can process images without any network connection at all.