How write-back works

Exactly what Inverity changes in your platform, and what it never touches.

Write-back is the step where an optimized file replaces or accompanies your original. It's the part people most want to understand before connecting a production library, so here it is in full.

The rule that governs everything

Inverity only writes back a file that passed the quality check. If the optimized result isn't smaller at equivalent visual quality, nothing is written and your original is left exactly as it was. See How optimization works.

There is one deliberate exception: video that had to be converted to MP4 for browser compatibility is written back even when it isn't smaller, because compatibility is the benefit. See Video optimization.

In a CMS

The optimized file takes the place of the original at the same location in your platform. Existing page references, embeds, and links keep resolving — that's the point of writing back in place rather than producing a new asset somewhere else.

Depending on your settings, Inverity either replaces the original with the optimized version or stores the optimized version alongside it.

In a DAM

DAM masters are treated as permanent. The optimized file is added as a new version or rendition of the existing asset rather than overwriting your master. Your version history records the change and your original stays retrievable through the DAM's own version controls.

For Cloudinary, the optimized file replaces the same public ID and Cloudinary keeps the version history, so your existing delivery URLs continue to work unchanged.

What Inverity never does

• It never deletes an asset. There is no code path that removes media from your platform.
• It never discards an original without a replacement. A file is only replaced by one that passed the quality check.
• It never changes dimensions. Optimization changes encoding, not size on screen.
• It never moves assets between folders, renames them, or reorganizes your library.
• It never touches assets outside your watched locations.

What it may change

• The encoded bytes of the file, obviously.
• Non-essential embedded metadata, which may be stripped as part of the saving. If your workflow depends on embedded IPTC or XMP fields, test a sample before a large run — see Image optimization.
• The container format for some video, where conversion to MP4 is needed for reliable playback.

Caching is the usual surprise

Write-back updates the file in your platform immediately. It does not — and cannot — clear caches that sit in front of it. Your CDN, your page cache, and your visitors' browsers may all still be holding the previous copy.

If your optimized images don't look any smaller when you test them in a browser, this is almost always why. See Delivery and caching.