Every client site I build ends up with the same four kinds of images in the assets folder: product screenshots from their admin panel, a gradient hero band, real product photos, and a handful of badges and soft-edged icons with transparency. For years I ran all of them through one batch script at a fixed quality and shipped. Then a client flipped a section background from white to dark grey, and the badge set I had delivered six months earlier showed a bright fringe around every edge. I had checked those on a white page. Rework on a fixed-price job is just unpaid work.
So I ran all four types through ImgIng one at a time and wrote down what actually needs checking for each. Same tool, same defaults, and the savings ranged from 60% down to 10%; one file came back completely unchanged. That spread is the useful part, so I'll go type by type.
Screenshots: check the text edges
My sample is a browser-rendered admin page I built for this, 1280×800, 94.0 KB. On upload the tool picked 8-bit color reduction on its own and returned a 208-color indexed PNG at 37.6 KB, 60% off. Pixel-for-pixel it came out at SSIM 1.000 and PSNR 60.7, so there was nothing to spot by eye. That makes sense: an admin UI is a few widget colors over large flat areas, and truecolor is mostly wasted on it.
The one thing worth checking here is the text. Zoom the output to 200% and look at body-size letterforms and thin table rules. When color reduction goes too far, large flat blocks survive fine; what breaks first is the thin ring of antialiasing grey around each stroke, and the copy starts looking furry.
Gradients: check whether it compressed just for the sake of it
The hero band, 960×480, 53.5 KB, came back at exactly 53.5 KB. The UI said the original was already the smallest option and the size was unchanged, and the downloaded file was byte-identical in size. My first thought was that the feature had failed.
It hadn't. A gradient is hundreds of continuous steps, and forcing it into one or two hundred colors leaves two options: visible banding, or dithering to hide the banding. Dithering scatters the pixel pattern so much that the lossless layer underneath stops finding anything to squeeze, and the file grows. Handing back the original beats handing back something bigger, or something striped.
This flipped a habit for me. I used to read a 0% result as a weak tool. Now I read it as a decision that was made on my behalf. Conversely, if some tool reports a beautiful ratio on a gradient, the first thing I do is open it full-screen and hunt for bands.
Photos: check whether the look and the size are both good enough
For photos I used a CC0 image from Wikimedia Commons (shot on an iPhone 6), 2048×1536, 638.7 KB. The default pass produced 578.0 KB at JPEG quality 88, 10% off, and that's it.
That's not laziness. The default has no idea whether the photo is a full-bleed hero or a 320px-wide list thumbnail, and those two tolerate very different quality levels. Photos are the one category where I always take over: I export the same file at two settings and look at both, pushing thumbnails into the mid-60s and keeping hero images above 80.
Transparency: check the edges on a dark background AND a light one
The badge and the soft icon are both mine, drawn for this test. Instead of fighting PNG, I exported to other formats. The badge went from 35.2 KB to 20.2 KB as WebP (43% off) and to 2.4 KB as AVIF (93% off). The 256×256 soft-edged icon went from 11.0 KB to 5.4 KB as WebP (51% off). All three kept their transparency graded rather than flattened — the drop shadow still fades continuously instead of turning into a hard cut.
That matters more than the size here, because everything valuable in a badge lives in that ring of semi-transparent pixels. Which is also why the check is: drop the output onto a dark background and a light one, and look at the edge in both. A damaged alpha edge is nearly invisible on white, since the fringe was fading into white anyway, and only shows up as a bright halo or a too-hard outline once the background goes dark. Two seconds per file, and it's the step that would have saved me that rework.
I did not switch everything to AVIF over that 2.4 KB. I didn't test old browsers or old devices in this round and I don't have the hardware to do it properly, so client sites that need coverage still get WebP as the baseline with AVIF as the first source in a picture element.
One practical note for anyone handling other people's assets: this all ran in the browser, and the compression step issued no upload request — you can confirm that in the Network panel yourself. Client files never leaving the machine has saved me a conversation on more than one project. The tool is at https://imging.ai/ .
Top comments (0)