Quality and output

When the optimized file isn't what you expected.

An asset shows "skipped — not smaller"

This is expected. The optimizer couldn't beat your original at equal quality, so it kept your original. See Results and savings.

The optimized image looks worse to me

First, confirm you're comparing correctly:

• Same zoom level, at 100%, on the same display.
• The actual optimized file, not a browser-scaled version of it or a cached copy of something else.
• The right asset — in a large run it's easy to compare the wrong pair.

If it genuinely looks worse, move that source to a more conservative quality profile and re-run the folder. Gradients — skies, studio backdrops, soft shadows — and small text are where an over-aggressive profile shows first.

Then tell support with the asset. An output that's visibly worse should have failed the quality check, and that's worth investigating rather than working around.

My transparent images came back with a background

They shouldn't. Transparency is preserved through the round trip. If you're seeing a flattened background, check whether something downstream — your CMS's own rendering, a template, or a derivative your platform generates — is doing the flattening. Then contact support with the asset.

My image dimensions changed

They shouldn't. Optimization changes the encoding, not the size on screen. If dimensions changed, the likely cause is a platform-side derivative or a resize rule in your CMS or DAM, not Inverity. See How write-back works.

My embedded metadata is gone

Non-essential metadata may be stripped during encoding, which is part of where the saving comes from. If your workflow depends on embedded IPTC, XMP, or copyright fields, keep those libraries on a conservative profile — or outside the watched scope — and verify a sample round-trip before a large run. See Image optimization.

My video won't play, or plays differently

If your source was in a format that doesn't play reliably in browsers, Inverity converted it to MP4 — and kept the converted file even if it wasn't smaller, because the compatibility is the benefit. That's the expected behaviour.

If the MP4 itself won't play in your target browsers, contact support with the original file details and the players you're testing in. See Video optimization.

Savings are lower than I expected

Savings depend almost entirely on how optimized your library already was. A library of raw camera exports has a lot of headroom; a library that's already been through a build-time optimizer has very little. Both produce correct results. See Image optimization.

Also check whether your delivery layer is already optimizing at the edge — a Cloudinary setup using f_auto,q_auto, for example, is already doing part of this job. See Cloudinary.