DEV Community: Jaydip Patel

I built 62 image tools that never upload your photos. Here's what was harder than expected.

Jaydip Patel — Mon, 05 Oct 2026 05:49:02 +0000

I do a lot of SEO and web work, which means I touch images every single day. Compress this one for a page, remove the background from that one, convert a HEIC someone sent me, resize something for a blog post.

And every day it was the same routine. One site for compressing, another for background removal, and another for converting. Half of them hit me with "upgrade to Pro" after one or two images. The rest were so full of ads I had to hunt for the actual download button. Some wanted me to sign up just to get my own file back. And all of them wanted me to upload the image to their server first, for something my laptop can easily do on its own.

At some point I got tired of it and started building my own. That became ImgKit: a set of image tools (compress, resize, HEIC to JPG, remove background, passport photos, that kind of stuff) with no upgrade wall, no ads, no account, and nothing uploaded. Everything runs in your browser tab. It's at 62 tools now, which is more than I planned, and I built most of it with Claude Code.

This post isn't an ad. It's what I learned building it, because a lot of it surprised me.

The setup is boring on purpose.

It's a Next.js static export on Vercel. No backend, no database, no API routes. That was the whole point: if there's no server, there's nowhere for your photo to go. It also means hosting costs me basically nothing.

The tradeoff is that everything has to work in the browser, including stuff you'd normally throw at a server.

"Compress to exactly 50 KB" sounds easy. It isn't.

This was the feature I thought would take an afternoon.

Canvas has toBlob(type, quality), so you just lower the quality until the file fits, right? Except quality doesn't map to file size in any predictable way. The same quality setting gives you 30 KB on one photo and 400 KB on another.

What I ended up with is a binary search over quality. Encode, check the size, go up or down, repeat. Seven steps gets you within about 1% of the best quality that still fits. And sometimes no quality fits, because the photo is just too big in pixels. In that case it scales the image down a bit and searches again.

Real example from my own testing: an 858 KB waterfall photo, target 50 KB. It came out at 43.2 KB, quality 17%, resized from 1600×1067 to 1372×915. Users see that note on the result, so nobody gets surprised that their image got smaller in pixels too.

The other thing: canvas.toBlob is not a great JPEG encoder. I switched the heavy lifting to WebAssembly builds of mozjpeg, oxipng and an AVIF encoder (the jSquash packages). Same quality, noticeably smaller files.

Running AI models in a browser tab

This was the fun part, and the part with the most surprises.

Background removal, upscaling, object removal and OCR all run locally with transformers.js and onnxruntime-web. The model downloads once, gets cached, and after that it works offline. Some numbers from testing:

Background removal uses MODNet, about 13 MB. First run includes the download. After that it's a few seconds on a normal laptop.
Object removal uses MI-GAN, 28 MB, and it's honestly fast. Under a second.
The upscaler is the slow one. On a laptop without a usable GPU it can take a minute, because it's all on the CPU. I had to cap input sizes and process in tiles so it doesn't freeze the tab.

Two things I didn't see coming:

WASM is single threaded for me. Multi-threaded WebAssembly needs special headers (COOP/COEP), and those break a bunch of other things on a static site. So every AI model runs on one thread unless the browser has WebGPU. That's the main reason some tools feel fast on one machine and slow on another.

Library versions matter a lot. I had to pin transformers.js to 3.7.5. The newer version's onnxruntime build just crashed for my models. No useful error, it just died.

For finding text in photos (for the "remove text from image" tool), I first tried Tesseract. It was bad at it. It missed white text on a light wall and "found" words in bicycle spokes. Switching to PaddleOCR's text detector (4.7 MB) fixed it.

The HEIC bug I didn't know I had

iPhones save photos as HEIC, which Windows still can't open by default. HEIC to JPG is one of the most used tools.

I was using a popular library called heic2any. Last week a security scanner flagged my site because my Content Security Policy allowed unsafe-eval. I dug in, and that permission was only there because heic2any compiles code at runtime. So I swapped it for heic-to, which has a build that doesn't need eval.

Then I compared the output of both, just to make sure nothing changed. Something did change. The old library had been making photos darker the whole time. Shadows crushed, reds too strong.

I measured how close each output was to the original photo (PSNR, higher is better):

Photo	Old library	New library
Waterfall	27.0 dB	36.9 dB
Portrait	26.7 dB	42.7 dB
Another photo	27.2 dB	38.7 dB

So a security fix ended up being a quality fix too. Nobody had complained, which probably just means people assumed that's how HEIC conversion looks.

While I was at it, I found one more Function(...) call that would've broken under a strict CSP. It was a feature check inside a Node util polyfill that JSZip pulls in. Using JSZip's prebuilt browser bundle instead got rid of it, and now JSZip only loads when someone actually downloads a ZIP.

The mistakes that were invisible

AI-assisted coding got features working fast. The things that bit me were the ones you can't see by clicking around.

I spammed Bing without knowing it. I set up IndexNow, which tells Bing when a page changes. My site has 113 pages. Bing's report showed 4,600 submissions. The sidebar lists every tool, so every time I added one tool, every page's content "changed", and the script resubmitted all of them. Same with my sitemap's lastmod dates: I was telling search engines 100 pages updated when really 2 did. The fix was simple once I saw it: ignore the header, nav, sidebar and footer when deciding whether a page changed.

Backlinks are mostly fake. Ahrefs showed 359 sites linking to me after a month. About 5 are real. The rest are domains like link-baron-syndicate-equity.store. That's apparently normal for new sites, but it was funny to see.

Bing still has 0 of my pages indexed. Google started showing the site within days. Bing lists my pages as "discovered, not crawled". Someone on X told me that's crawl priority for a new domain, and the fix is real links, not more pings. I think they're right.

Was it worth doing it all in the browser?

For this kind of tool, yes. The image is already on your device. Uploading it somewhere just to shrink it never made much sense to me.

It's not free though. You're limited by the user's hardware, big models need a download, and you can't fix a slow CPU from your side. If I needed collaboration or storage, I'd want a server.

You can check the privacy claim yourself, by the way: open DevTools, go to the Network tab, run a tool, and watch. Nothing goes out except the model downloads. Or just turn off your Wi-Fi after the page loads.

What's next

Honestly, less building and more talking to people. I built 62 tools and then realized I don't know which 5 people actually need. If you try it and something's missing or broken, I'd really like to hear it.

It's free, no account: imgkit.xyz

If you've run ML models in the browser, I'm curious what your experience was with WebGPU vs plain WASM. That's the next thing I want to figure out.

How to compress an image to an exact file size in the browser

Jaydip Patel — Sat, 26 Sep 2026 13:48:55 +0000

Upload forms don't ask for "quality 70". They ask for "under 50 KB". Exam portals, visa applications and job sites all do it, and a phone photo is 3–5 MB, so the gap is a factor of fifty or more.

A quality slider doesn't answer that question. There's no quality setting that means 50 KB, because the same setting gives a 30 KB file for a plain portrait and a 300 KB file for a busy street scene. You have to search for it.

This is how I built exact-size compression in ImgKit, which runs entirely in the browser. Nothing here needs a server.

Step 1: binary-search the quality

For JPEG and WebP, file size goes up as quality goes up. It isn't perfectly smooth, but it's close enough that a binary search works: try the middle, keep whichever half still fits.

async function fitQuality(canvas, type, maxBytes) {
  const encode = (q) =>
    new Promise((resolve) => canvas.toBlob(resolve, type, q));

  let lo = 0.1, hi = 0.95;
  let best = await encode(lo);
  if (best.size > maxBytes) return null; // quality alone can't get there

  const top = await encode(hi);
  if (top.size <= maxBytes) return top;  // already fits at high quality

  for (let i = 0; i < 7; i++) {
    const mid = (lo + hi) / 2;
    const blob = await encode(mid);
    if (blob.size <= maxBytes) { best = blob; lo = mid; }
    else hi = mid;
  }
  return best;
}

Seven steps narrow a 0.1–0.95 range to about 1% of quality, which is well past the point anyone can see a difference. Two things are worth getting right:

Keep the best blob that fit, not the last one tried. The final midpoint is often just over the limit.
Check both ends first. If the lowest quality is too big, searching is pointless. If the highest already fits, there's no reason to throw quality away.

Step 2: when quality isn't enough, shrink the image

A 12-megapixel photo at quality 10% can still be 400 KB. At that point the only lever left is the number of pixels.

File size is roughly proportional to pixel count, and pixel count goes with the square of the side length. So if the smallest encode is 4× too big, shrink each side by about √(1/4) = ½:

const factor = Math.sqrt(maxBytes / smallest.size) * 0.92;
width = Math.round(width * factor);
height = Math.round(height * factor);

The 0.92 is a safety margin: the relationship isn't exact, and undershooting slightly means one resize instead of two. Then run the quality search again at the new size. Cap the number of attempts and stop at a sensible minimum side (I use 64 px), so an impossible target fails with a clear message instead of producing a thumbnail.

Step 3: search with the fast encoder, finish with the good one

The browser's built-in encoder (canvas.toBlob) is fast but not very good. MozJPEG, compiled to WebAssembly, typically fits the same picture into 10–30% fewer bytes. It's also 15–25× slower. A search that has to resize a few times can run dozens of encodes, so doing all of it with MozJPEG would take several seconds per photo.

So the search runs with the fast encoder, and only the final file uses the good one. That creates a subtle problem. Suppose the fast encoder found that quality 25% fits 50 KB. MozJPEG at 25% might come out at 38 KB, which leaves 12 KB of budget unspent. The user gets a worse-looking photo than necessary.

The fix is a short second search, with the real encoder, upward from where the first one stopped:

let best = await mozjpeg(canvas, bestQuality); // same quality, fewer bytes
let lo = bestQuality, hi = 0.95;
for (let i = 0; i < 4; i++) {
  const mid = (lo + hi) / 2;
  const candidate = await mozjpeg(canvas, mid);
  if (candidate.size <= maxBytes) { best = candidate; lo = mid; }
  else hi = mid;
}

Four extra encodes costs about 0.3 seconds and spends the leftover budget on quality. The file still fits, and it looks as good as the limit allows. I use jSquash for the WebAssembly builds of MozJPEG and OxiPNG. They're the same encoders Squoosh uses.

The details that bite

Transparency turns black. JPEG has no alpha channel, so a transparent PNG drawn onto a canvas and saved as JPEG gets black where it was clear. Fill the canvas with white before drawing.
iOS Safari has a canvas size limit of roughly 16.7 megapixels. A big photo just fails to get a context. Check for that and start from a scaled-down size instead.
The original may already fit. If the file is under the target and the user didn't ask for a format change, return it untouched. Re-encoding a small JPEG can make it bigger and always costs a little quality.
HEIC needs decoding first. Browsers other than Safari can't draw HEIC, so iPhone photos need a decode step before any of this starts. I use heic2any, a JavaScript build of libheif.

Result

The file lands just under the limit rather than well below it, so none of the size budget is wasted. Everything happens in the tab, so it works offline and the photo never leaves the device.

If you want to see it working, it's the compress to 100 KB tool on ImgKit. I built it, so treat the plug accordingly. The approach works for any encoder that takes a quality setting, and the whole thing is about 200 lines.