While rebuilding the Daminion website, we started paying more attention to something fairly mundane: image files.
Some pages contained old JPEGs. Designers were exporting PNGs. Product screenshots came in at different resolutions. AI-generated images looked ready to publish but were often much larger than the page actually needed.
At first, the obvious solution seemed to be:
Let’s just convert everything to WebP.
That helped.
But it didn’t actually solve the problem.
A 3000px-wide WebP is still oversized if the layout displays it at 1200px. A compressed publishing image shouldn’t become the only copy of an asset. And blindly applying the same quality setting to every image can produce wildly different results.
The real problem was the publishing workflow.
One quality setting, very different results
While testing our WebP workflow, we saw just how inconsistent compression can be depending on the source image.
One image went from:
2.94 MB → 149.51 KB
That’s roughly a 95% reduction.
Another high-resolution photograph, using the same 80% quality setting, went from:
6.29 MB → 4.59 MB
Only about 27% smaller.
More recently, we tried the same process with an AI-generated forest image.
The downloaded PNG was 2.94 MB.
After preparing it for the web and converting it with our WebP tool, the result was:
324.24 KB — 89.2% smaller.
Same general process. Very different outcomes.
That was a useful reminder that there is no magic “WebP saves X%” rule.
Visual complexity, dimensions, source encoding, compression level, and the type of image all matter.
The workflow we ended up using
What works better for us now is simple:
- Keep the highest-quality original.
- Crop it for its actual destination.
- Resize it to something close to its real display size.
- Choose the appropriate format.
- Compress it.
- Compare the result visually.
- Publish the optimized version — not the master.
For most raster website images, WebP became our default.
But not for everything.
We still prefer SVG for logos and simple vector graphics. PNG makes sense when lossless detail really matters. AVIF can be interesting when maximum compression is worth the extra workflow complexity. JPEG is still useful when compatibility with older systems matters.
So the question changed from:
What is the best image format?
to:
What format makes sense for this asset, in this workflow, for this destination?
AI-generated images made the problem more obvious
This became even more noticeable once AI-generated visuals entered our content workflow.
An AI image often looks finished the moment it is generated.
That creates a temptation to download it and publish it immediately.
But “visually ready” and “ready for the web” are different things.
An AI-generated image may still be:
- much wider than the layout needs,
- saved as a heavy PNG,
- using the wrong aspect ratio,
- missing a properly prepared publishing version.
We now treat AI output the same way we treat a designer’s master file: it is the source asset, not necessarily the file that should be delivered to a browser.
WebP turned out to be the easy part
The most useful thing we learned wasn’t that WebP is better than JPEG or PNG.
It was that image optimization becomes much easier once the publishing decision is repeatable.
Instead of asking someone to make five technical decisions every time they upload an image, we now have a default process:
master → crop → resize → optimize → review → publish
The file format is just one step in that chain.
I wrote up the full comparison — including WebP vs JPEG, PNG, SVG and AVIF, real compression examples, and the publishing workflow we now use — here:
Best Image Format for Web: WebP vs JPEG, PNG, SVG & AVIF →
We also turned part of this workflow into a free browser-based WebP converter, mostly because we needed something quick ourselves:
