INITIALISATION DU SYSTÈME...
A remote service has to receive your photo intact before cleaning it. A comparison of both models, plus two simple tests to verify for yourself where the work happens.
A tool that cleans your photos 'online' can work in two radically different ways: either the work happens in your browser and the file never leaves, or it happens on a server and you must upload the photo intact, metadata included, before any cleaning. The displayed result is identical; what changes is who has seen your file.
Handing a photo to a remote service to strip its sensitive data means starting by sending it that data. The image lands on the server with its GPS coordinates, its exact date and its device identifier. Removal happens after that transmission.
In between there is at minimum one copy of the file: in memory, in a disk cache for the duration of the job, often in access logs. You have no way to check what became of it. The privacy promise then rests entirely on the provider's word, where the local model makes it unnecessary.
| Criterion | Processing in the browser | Processing on a server |
|---|---|---|
| File leaves the device | No | Yes, intact and before cleaning |
| Verifiable by the user | Yes, Network tab or airplane mode | No, the server is opaque |
| Works offline | Yes | No |
| Privacy rests on | The architecture | The terms of service |
| Technical limit | Device memory | Upload size, queue time |
| Bulk processing of large volumes | Bounded by the device | More comfortable |
The remote model keeps a genuine edge on very large volumes, where a server outmatches a phone. That is a deliberate trade: privacy exchanged for convenience, and it is better made knowingly.
The point of local processing is that it is verifiable. Two checks are enough, and neither needs any particular skill.
Both tests apply to any tool, ours included. The security page describes exactly how GhostMeta works.
The padlock in the address bar attests that the connection is encrypted in transit. It says nothing about processing on arrival. The server necessarily decrypts what it receives in order to work on it: at that moment your photo sits in the clear on a machine you do not control.
HTTPS therefore protects against a third party listening on the line, not against the recipient. It is a useful and necessary protection, but it answers a different question from the one at hand.
The image is decoded in the tab's memory, redrawn through the browser's Canvas API, then exported again. The canvas returns pixels and nothing else: every metadata block is lost on write, by construction rather than by filtering. No network request carries the photo, which both tests above confirm in seconds.
These questions cover where the processing happens. For what the metadata contains, see the EXIF and GPS guide and the questions hub.
Open your browser's developer tools on the Network tab before dropping the file, then watch the requests it triggers. Local processing produces none that carries the image. An outgoing request the size of your photo is the signature of an upload.
Yes, and it is the simplest test there is. Load the page, cut the network, then process an image. If it completes offline, the work is genuinely happening on your device. If it fails or hangs, the file had to go somewhere.
No. HTTPS encrypts transport, between your browser and the server. It says nothing about what the server does with the file once received: decrypted on arrival, it can be logged, cached or retained. Encrypting the journey is not the same as having no journey.
That depends entirely on its terms, and you have no technical way to verify it. Many advertise deletion after a few hours, which implies they stored the file first, and often cached and backed-up copies alongside it.
Not necessarily. An extension holds standing permissions and updates itself, sometimes after a change of ownership. A web page has no persistent access to your files, and its behaviour is observable request by request on every visit.
Yes, within the memory available on the device. That is the real trade-off of the local model: a modest phone will handle a very large image more slowly than a server would. GhostMeta caps output resolution at 4096 pixels to avoid memory crashes on mobile.