Legal sat with my team for three months during last year's data compliance review. On the way out they left one sentence: if a user-uploaded image passes through any hop outside our network, we have to be able to say where it went, how long it stayed, and who could read it. Saying that is hard, so our answer became: don't let it leave. In a situation like this you look at where processing happens before you look at how many features there are. Missing features can be added. A link in the chain that leaves the network can't be walked back.
We re-shortlisted image tools after the review with three criteria: does the file leave the device, is common-format coverage enough, and how much do we have to change to adopt it. The first one eliminated nearly everything. Online tools are overwhelmingly upload-process-download, and however well their privacy policy reads it's still an unverifiable promise. Legal doesn't accept promises, it accepts chains. That isn't us being difficult — the audit wants a diagram of the chain, and "they say they delete it" doesn't go in a box.
Among what survived, the client-side path clears it because the work moves into the browser. I went with ImgIng, not because it has the most features but because that one claim can be self-evidenced: open DevTools, Network tab, process an image, no upload request, preview src is a blob: URL living in browser memory. It's at imging.ai. Coverage turned out to be sufficient in practice too — compression, format conversion, AI background removal, an animation workshop, multilingual OCR, an image editor and AI upscaling, plus PDF compression, PDF to image, extracting embedded originals, content extraction and HTML in both directions. DOCX and PPTX to standalone offline HTML was an unexpected bonus; we ship a batch of read-only documents to external parties who may not have Office. The third criterion was trivially satisfied because it's a web page — no integration cost at all, which matters a lot for teams like mine where ad-hoc requests outnumber funded projects.
Where I don't use it
Not for the batch pipeline. We have a nightly job that processes a few thousand product images on a server using a command-line tool, and the client-side approach has no advantage there — its value is that files don't leave the user's device, and files already sitting on our servers are inside the network anyway. Not for HEIC writing or TIFF either; those go to their server, colour-coded in the UI, and while it's their server, outside our network is outside our network. Which is why whenever I say "images aren't uploaded" I add the qualifier: it holds only for the features you actually use.
Two things still open
Performance leans on the client. Company-issue laptops are middling, and running AI background removal on one is noticeable, plus the model has to load the first time. That's the trade this path makes and there's no having it both ways. The other is that I have no usage data — nothing is uploaded, so there are no server logs, and I have no idea who's using it, where they get stuck or how often it fails. I still haven't worked out what to do about that: adding telemetry cuts against the whole "nothing gets sent" premise, and not adding it means working blind. For now I rely on colleagues mentioning things, which is unreliable, but it'll do for the moment.
Top comments (0)