# I built an image toolbox that keeps common processing inside the browser

> Source: <https://dev.to/fgghyyfk/i-built-an-image-toolbox-that-keeps-common-processing-inside-the-browser-oob>
> Published: 2026-08-25 03:50:40+00:00

I work with product images every day. The usual workflow was surprisingly annoying: one site for compression, another for format conversion, another for background removal, and another for animated images. Most of them required uploading the original file.

So I built Imging as a local-first browser tool. Common image work stays on the device: JPG, PNG, WebP, AVIF and HEIC conversion, compression, background removal, and GIF/APNG/animated WebP editing. Larger codecs and models load only when a feature needs them.

The main engineering lesson was that “runs in the browser” is not one capability. Decoding, canvas processing, encoding, WebGPU inference, WASM fallback, memory limits and file saving all fail independently. I now test each capability instead of assuming support from the browser name.

Background removal prefers WebGPU and falls back to WASM. Animated images go through a frame pipeline so timing and loop information can be kept while frames are edited or recompressed. PDF compression rewrites the document structure instead of turning every page into a large bitmap.

There are still honest limits. Some uncommon formats cannot be handled completely in the browser, mobile memory is tight for large animations, and HEIC files are not always consistent. The tool reports those cases instead of pretending every operation is local.

Imging is free to use without an account or watermark:

I used AI-assisted coding during development, but the capability checks, processing boundaries and validation cases came from the actual product-image workflow.