Reducing a PNG safely requires knowing why the file is PNG in the first place. Transparency, exact edges, interface text and flat colors can be more important than a nominal size target.
Start with a source inspection
Record the image dimensions, whether it has an alpha channel, whether it contains text or line art, and where it will be used. If the file is a source for later editing, keep it untouched and create a separate web copy.
Test one copy at a time
- Process one representative image rather than the whole folder.
- Compare input and output bytes and dimensions.
- View transparent areas on contrasting backgrounds.
- Inspect small type, thin lines and colored edges.
- Open the result in the final CMS, browser or application.
When conversion is reasonable
A transparent web graphic may work well as WebP or AVIF if the delivery environment supports it. A PNG that must be consumed by an older application or a design workflow may need to remain PNG. Compatibility is part of the result.
When no reduction is a valid outcome
If a PNG has already been optimized or its content is difficult to compress, a second operation may produce little change. Keep the original result, document the test and avoid claiming a saving that was not observed.
Separate the source from the delivery copy
Keep the original PNG in a source or archive location and create a named delivery copy for the website. This makes it possible to change dimensions, restore transparency or choose a different format later without starting from an already modified file.
Acceptance checks
A delivery copy is ready when it opens in the target browser or CMS, has the intended dimensions, preserves the required alpha channel, keeps text and edges legible, and has a recorded input/output comparison. If one of these checks fails, revert to the source and test a different setting.
Acceptance details
A result is acceptable only when it meets the destination requirement, opens correctly and passes the visual or technical check described above. The output may be smaller, similar in size or larger than the source; record what actually happened instead of replacing the observation with a target percentage.
Inspect transparency before export
A checkerboard shown by an editor is only a preview of transparency. Verify the alpha channel by opening the output over a light and a dark background, and inspect semi-transparent edges around text, icons and product cutouts. A white-looking background can mean that transparency was removed or that the viewer is displaying a matte color.
If the PNG becomes larger
A larger result is not automatically a failure of the tool. The source may already be optimized, metadata may be retained, or the image may be better represented in another format. Compare the dimensions and visual requirements first; then test a delivery copy in WebP or AVIF only when the target environment supports it. Keep whichever output meets the destination requirements and document why.
Final PNG acceptance checklist
Before publishing, confirm the output opens correctly, has the intended dimensions, retains the required alpha channel, keeps text and thin edges legible, uses the expected filename and remains editable from the original source. If a CMS transforms the file after upload, repeat the check on the served asset rather than relying only on the local download.
Sources and further reading
MDN’s image format guide explains PNG transparency and alternative formats. web.dev’s image performance guide recommends experimenting with format and compression while checking quality.