LimiFile

I’ve been building LimiFile, a free collection of browser-based image tools.

The product makes a fairly specific privacy claim: selected images are processed on the user’s device and are not uploaded to a LimiFile server.

At first, I thought of that mostly as an architecture decision.

Then I realized it was also something I could accidentally break later.

A future refactor could introduce a network call in the wrong place, or pass a selected file into something that sends data elsewhere. “It runs in the browser” wouldn’t protect me from that.

So I added regression tests around the claim itself.

For several processing flows, the tests watch browser APIs such as fetch, XMLHttpRequest, FormData, and, for PNG compression, sendBeacon. The goal is to catch selected File / Blob data being passed into a path that could transmit it.

The tests don’t cover every tool and every possible path yet, so I don’t treat them as proof that transmission is impossible. They’re a regression barrier for the flows they cover today.

I also open-sourced the full web app so the processing code, tests, analytics layer, build configuration, and dependencies can be inspected.

LimiFile currently handles things like HEIC / HEIF → JPG, image compression, PNG / WebP / AVIF conversion, EXIF / GPS removal, fixed-size compression, and signature resizing.

It’s still early, and I’m trying to avoid adding tools just to make the list longer.

I’d especially like feedback on:

• whether processing selected images locally actually matters to you

• which image or file problems still make you go looking for another tool

• anything about the privacy wording that sounds unclear or stronger than the implementation supports

Website: https://limifile.com/

Source: https://github.com/Sotaro-Kato443/limifile