Why your resized image looks blurry — and how to actually fix it

Resize a photo down for the web and it comes out a little soft — not corrupted, not pixelated exactly, just noticeably less crisp than the original. The instinct is to blame JPEG compression, since that's the usual culprit for image quality complaints. Often it isn't. The blur shows up even when you resize into a lossless PNG, which means the loss happened during the resize itself, not the encoding step afterward.

Every browser-based resize tool, ours included until recently, works by drawing the image onto an HTML canvas at the new dimensions and reading the pixels back out. That single `drawImage` call is doing the actual scaling math, and it's governed by a setting called `imageSmoothingQuality` that most code never touches. Left at its default, Chrome and Edge use a cheap, fast filter — not the sharper one they're fully capable of — because the canvas API is built for speed by default, not fidelity. You have to explicitly ask for `"high"`. A lot of tools, including image libraries bundled into other sites, simply never do.

Setting that flag helps, but it doesn't fully solve the problem for a large reduction — shrinking a 4000-pixel photo down to 400 pixels, say. A single scaling pass that big still looks softer than it should, because there's no browser-native equivalent of the mipmapping that desktop image editors use internally: instead of jumping straight from full size to the target, they halve the image repeatedly, each step at a ratio small enough that the filter has actual detail to work with, until they're close to the final size. Skip that and you're asking one resize operation to do work it wasn't designed to do well.

That's the fix we shipped across the resize, crop, rotate, and convert tools here: every canvas draw now explicitly requests high-quality smoothing, and any resize that shrinks an image by more than half runs through the same progressive step-down approach — halving, halving again, until it's within range of the target size, then doing the final draw. It's a few extra canvas operations per image, invisible in terms of speed, and it noticeably changes how sharp the output looks side by side with the original.

Worth being upfront about what this doesn't fix: converting a PNG to JPEG is still a lossy step no matter how good the resize is, because JPEG compression throws away information the format was designed to discard — that's a format trade-off, not a bug. Canvas also normalizes color to sRGB, so a photo shot in a wide-gamut profile like Display P3 can shift slightly in color, not just sharpness, when it passes through any browser-based editor, not only this one. Neither of those is something a smarter resize algorithm can undo. If you need maximum fidelity, keep the output in PNG or WebP and treat any JPEG re-encode, ours or anyone else's, as a deliberate trade rather than a free operation.