Most online image compression and converter tools work the same way: you upload your photo to their server, their server does the work, you download the result. That architecture has two problems — the owner pays for every byte of compute (which is why they all have quotas and paywalls), and your files end up on someone else's machine.
I wanted to see how far I could get with neither. The result is ImageCompressify — image compression and conversion for 40+ formats, running entirely in the browser. No upload, no server bill, no quota. Building it was straightforward in some places and genuinely hard in others, and the hard parts are what this post is about.
Why client-side at all
Three reasons, in honest priority order:
- Cost: I'm a solo founder. A server-side image pipeline means paying for CPU on every conversion, forever, including for free users. Client-side means my infrastructure bill is a static site.
- Privacy as a feature, not a slogan: "We delete your files after 1 hour" requires trust. "Your file never leaves your device" requires nothing — you can verify it yourself in the Network tab.
- Speed: No upload + no queue + no download often beats a fast server, especially on large files and slow connections. The round trip is the bottleneck for most users.
The part nobody warns you about: real-world files
The common web formats are the easy part — browsers handle them natively, and that corner of the market is saturated precisely because it's a weekend project. The work that took months was supporting formats browsers have never heard of: professional camera and design formats with decades of accumulated quirks.
And here's the lesson that cost me the most: the spec you tested against is never the spec users have.
My favorite production bug: support for a popular design format worked perfectly through all my testing, then real users started getting silently broken output. The culprit was a higher bit-depth variant of the format — the kind professional workflows export and casual test files never use. The internal data layout differs, and my pipeline produced garbage without erroring.
Two lessons from that week:
- Real-world files are a zoo. Bit depths, color profiles, compression flags, encoder quirks — whatever subset you tested, production will send you the rest.
- Fail loudly. Silently wrong output is far worse than an error message. Anything outside the verified path should say "this variant isn't fully supported yet" instead of pretending.
Constraints you only meet client-side
- Memory is the real quota: There's no server limit, but a huge decode can OOM a phone tab. You have to think in terms of the user's device budget, downscale progressively, and release buffers aggressively.
- Old laptops are your slow tier: Server-side, you control the hardware. Client-side, your P95 latency is someone's 2017 laptop doing heavy encoding. Be honest in the UI/UX about long operations instead of faking instant.
- The main thread is sacred: Any serious processing on it freezes the page. Everything heavy runs off-thread; the UI only ever touches results.
- Ship lazily: Supporting many formats means a lot of decoding code. Sending all of it to every visitor would be megabytes — load per actual need, not per possibility.
Was it worth it?
Architecturally, yes. My marginal cost per image is zero, which is why the core tool can stay free. And the formats that were hardest to support turned out to be the most rewarding — solving what everyone else skipped is where users are most grateful.
One thing I'll say plainly: the code is not the hard part of a product like this — especially now, when AI coding tools can scaffold a converter in a day. The hard parts are the long tail of broken real-world files, earning users' trust with their photos, and getting anyone to find you at all. None of those ship overnight.
If you're building a tool where the computation can run on the user's device, seriously consider letting it. The browser is a far more capable runtime than most backend give it credit for.
Happy to answer questions about the weird-file-format archaeology in the comments.
Top comments (1)
*Really interesting perspective. Building an image tool that runs entirely in the browser solves both privacy and cost issues. It's impressive how much can be achieved with client-side technologies today.*