Building Image Tools That Never Upload Your Images

Local first

Image Toolkit began with a simple constraint: an image tool should not need to upload the image to a server just to resize it, convert it, or make a smaller copy. That decision shaped more than the interface—it shaped how each tool works.

The original file is decoded and processed in the browser using browser APIs and an in-memory canvas. Resize and Convert fit this model naturally: the browser draws the source at the requested dimensions, encodes the output, and creates a local download.

This is useful for images that are personal, unfinished, or simply inconvenient to upload. It also means there is no account, upload queue, or server-side image-processing pipeline involved in the operation.

Compression should actually compress

“Compress” is an easy word to overpromise.

For JPEG and other lossy formats, lowering quality can often reduce file size. PNG is different. Re-encoding a PNG through canvas may produce a smaller file, but it is not guaranteed to. Depending on the source and browser encoder, the result can be the same size or larger.

Calling every re-encoded PNG “compressed” would hide that fact. Image Toolkit follows a simple rule: if the result is not smaller, don't call it compressed.

In that case, the original remains available and the tool reports that no smaller result was found. The user asked for a smaller file, not simply a newly encoded one.

The same principle keeps format conversion separate. Converting PNG to WebP may produce a smaller file, but it is a format change with its own trade-offs. That decision belongs in Convert, where it is explicit, rather than being presented as PNG compression.

Background removal, still local

Remove Background needs more than canvas encoding. In V1, Image Toolkit lazily loads U2NetP and ONNX Runtime Web's WASM runtime only when background removal is used. Inference then runs on the user's device, without uploading the source image for processing.

The model produces a mask that the browser applies to the original pixels to create a transparent PNG. Background colors are composited from that local cutout afterward, so changing the background does not require another inference pass.

There is a trade-off. The model and runtime need to load, the user's device does the work, and V1 does not pretend that every extraction will be perfect. Fine details and difficult edges can still produce imperfect results.

Local-first wasn't just a privacy decision. It determined where the work runs, which trade-offs are acceptable, and even what the product is allowed to call a successful result.