We built a toolkit that never sees your files — here is why
When I started SnapTools, the easy choice was to put a server in the middle. Every popular image tool does: you upload a photo, the server runs ImageMagick or a cloud API on it, you download the result. It would have been faster to build, easier to scale, and friendlier to phones with limited memory. I chose not to, and that single decision is the reason this site exists at all.
The case against receiving your photo
A server-side tool is convenient for the builder but it asks the user for trust on every visit. Trust that the file is deleted after processing. Trust that nobody on the team looks at it. Trust that there is no logging of filenames, that backups do not keep a copy, that a future acquisition of the company does not change the policy. A small image site can do all the right things today and still be wrong tomorrow, because the moment the file lands on a disk you control, you have to defend it forever.
Doing the work in the browser is a different bargain. The browser's canvas API and modern JavaScript can do most of what ImageMagick can, on files that never leave the device. The user does not have to trust us with the file because we literally never receive it. I can disappear and the property is still intact on their machine.
What this means in practice
It means compressing 50 photos does not require a fast connection. It means the watermark tool is safe to use on client work, unreleased product shots, or a passport scan. It means a Wi-Fi QR code can be generated for a guest network without the password being typed into anything that phones home. It means if you disconnect from the internet, the site keeps working — which is, in my opinion, the easiest way to verify the claim yourself.
What we give up
Honest list, in case you are weighing similar trade-offs:
- No HEIC decoding. Apple's HEIC format requires a hefty decoder that browsers do not ship natively. We could ship a 1–2 MB WebAssembly library to handle it, and we may eventually, but today the image converter honestly only handles PNG, JPG and WebP. We will not pretend otherwise.
- No AVIF encoding. Same problem: the canvas API has no AVIF encoder, and AVIF's encoder is much heavier than the WebP one. There is a full write-up of why in the formats section.
- Batch size is limited by your device. A laptop with 16 GB of RAM will comfortably process a few hundred photos; a phone will hit its memory ceiling long before that. Server tools can shard the work; we cannot.
- No cross-device sync. If you close the tab, your files are gone. That is the right answer for privacy, and the wrong answer for convenience. We pick privacy.
What we keep
The site is small, the tool count is small on purpose, and the about page explains who pays for it. There is no premium tier, no daily quota, no watermark stamped on your output. I think the most useful thing I built is also the most boring: the decision, repeated on every page, to do the work in your browser instead of mine. Everything else is a consequence of that.
Frequently asked questions
How can I verify nothing is uploaded?
Open the network tab in your browser's developer tools, then use any tool. You will see that the only network request is the page itself and its assets — no image data ever leaves the page. You can also turn off Wi-Fi and continue using the tools; they keep working.
Why not offer both? A local mode and a server mode?
Because the moment a server option exists, some people will pick it for the wrong reason (a phone with low memory, say) and lose the privacy guarantee without realising it. Keeping the architecture uniform — browser-only — is the only way to make the promise simple to keep.
Is anything logged on your side?
Our hosting provider records standard server logs (IP, browser, request time) the way every web host does. We do not add anything to those logs, and we do not run analytics that include the contents of your work. Full details are in the privacy policy.
Do you have a roadmap?
Yes — how the site is funded and what we plan to build next are written down in plain English. Nothing in there is private or surprising, but I would rather the roadmap be public than be inferred from git history.