DEV Community

Cover image for Why I Built an Image Converter That Never Touches a Server
Monir bouakaz
Monir bouakaz

Posted on

Why I Built an Image Converter That Never Touches a Server

The problem: every "free" image converter wants your files

If you've ever needed to quickly convert a batch of photos to WebP or shrink a folder of PNGs before shipping them to production, you've probably run into the same annoyance I did: most "free online converters" require you to upload your files to a remote server first.

That's fine for a random screenshot. It's not fine when the images are:

Unreleased product shots under NDA
Client assets you're not supposed to redistribute
Personal photos you'd rather not hand to a third-party server you know nothing about

So I started looking at what the browser can actually do on its own — and it turns out, more than most people assume.

What the browser can already do

Modern browsers ship with everything needed to decode, resize, re-encode, and compress images entirely client-side:

+ toBlob() / toDataURL() for re-encoding to JPG, PNG, or WebP
The File API for drag-and-drop and batch uploads
Web Workers to keep the UI thread responsive during batch conversion
JSZip (or similar) to bundle multiple converted files into a single downloadable ZIP

None of this requires a backend. No image ever has to leave the user's machine.

Why this matters beyond privacy

Besides the obvious privacy win, doing conversion in-browser has some nice side effects:

No server costs that scale with usage. A traditional image-conversion API has to provision compute for every request. A client-side tool scales for free — the user's own CPU does the work.
No upload/download round trip. For large batches, skipping the network entirely is often faster than uploading to a server and waiting for a processed file back.
Works offline once loaded. A PWA-style client-side converter keeps working even with a flaky connection.
The trade-offs

It's not free lunch:

Very large batches (hundreds of high-res images) can strain the main thread if you're not careful with Web Workers.
WebP/AVIF encoder quality and speed vary by browser engine, so you can't guarantee byte-identical output across Chrome/Firefox/Safari.
You lose server-side control — no easy way to enforce a max file size before the browser has already loaded the image into memory.
Where I landed

I ended up building this into a small tool, ImagArt AI, that converts and compresses images to JPG, PNG, or WebP directly in the browser, with batch upload and ZIP export. It's free, and since nothing is uploaded, there's no privacy trade-off to think about.

If you're building something similar, happy to compare notes on Web Worker batching or encoder quality settings — drop a comment below.

Top comments (0)