Image optimization layers can rewrite PNG filters, compression, metadata, dimensions, or even format while preserving a similar visual result.
The URL is not always the stored object
Modern image delivery services can transform assets at request time or cache a derivative. The bytes received by the browser may therefore be generated from the origin asset rather than copied verbatim.
Lossless rewrite still changes hashes
An optimizer can choose new PNG filters, Deflate parameters, IDAT boundaries, or metadata while reconstructing identical pixels. A cryptographic hash of the delivered file will change even when the decoded raster does not.
Metadata is a common casualty
Text, timestamps, EXIF, color profiles, and physical-dimension chunks may be retained or stripped according to service configuration. Color metadata deserves particular care because removing it can affect interpretation.
Some systems negotiate another format
An image URL ending in .png does not guarantee that every client receives image/png if the service performs content negotiation. Check the HTTP Content-Type and actual response bytes rather than relying on the path suffix.
Debug at both ends
Save the origin object and the delivered response. Compare dimensions, MIME type, PNG chunks, decoded pixels, and headers. This separates an export problem from a delivery transformation.
Define invariants for your pipeline
Decide what must remain stable: visual pixels, alpha, color appearance, metadata, byte identity, or URL semantics. You cannot meaningfully test an optimizer until you know which of those properties are requirements.
Sources and technical basis
Primary technical reference: W3C Portable Network Graphics (PNG) Specification, Third Edition (2025). Web-delivery sections also use MDN guidance for responsive images where relevant.
