An indexed PNG stores palette references instead of full color values for every pixel. If an editor expands it to truecolor and saves it that way, the picture can look unchanged while the file becomes much larger.
PNG → WebP
Understand what the palette is saving
In an indexed-color PNG, the PLTE chunk stores palette entries and each pixel refers to one of those entries. This can be efficient for icons, diagrams, pixel art, and other graphics with a limited color set. The indexed color type can use up to 256 palette entries. Transparency values can also correspond to palette entries, allowing selected colors to be fully or partially transparent.
A truecolor PNG represents color samples directly for each pixel, with an alpha component as well when the image uses RGBA. That model is appropriate for photographs, complex gradients, and many translucent colors, but it can require more data. Two files can appear identical while using different color types, bit depths, filtering choices, ancillary chunks, and compression decisions, so their byte sizes may differ substantially.
- Check whether the file uses PLTE
- Count the colors actually needed
- Review how transparency is represented
An indexed PNG can stay compact because many pixels reuse entries from one limited palette.
A minor edit can expand the entire image
An image editor may expand an indexed PNG into an RGB or RGBA working space as soon as it opens the file. Adding a layer, soft brush, shadow, translucent effect, or color adjustment can introduce many values that were not in the original palette. Unless the export step deliberately returns the artwork to an indexed mode, the saved PNG may remain truecolor even if only one label was changed.
Rotation and resizing can also create intermediate edge colors and many alpha levels through resampling. Forcing that result back to 256 colors can produce rough edges, posterization, or bands in gradients. A larger output is not automatically an encoder error. First determine whether the edit genuinely created color or transparency complexity that the previous palette could not represent cleanly.
- Review layers and translucent effects
- Inspect new colors after resampling
- Check the export color type
The visible edit can be small while the editor changes the storage model for every pixel.
Do not confuse lossless with identical size
PNG is designed so the encoded raster can be reconstructed without the type of generational loss associated with JPEG. That does not require every encoder to produce the same bytes. Palette use, truecolor samples, alpha, bit depth, row filters, compression strategy, and metadata can all change the final size. Re-saving may preserve the displayed pixels while producing a larger or smaller file with a different internal organization.
Control the comparison before blaming the palette. Confirm equal width and height, identical crop, and the same visible content. A larger canvas or invisible transparent padding adds pixels even when the artwork appears unchanged. Color profiles, textual chunks, timestamps, and application-specific information can also add bytes. Inspect these causes separately so a metadata increase is not mistaken for a color-type conversion.
- Compare identical pixel dimensions
- Look for transparent padding
- Separate color type from ancillary data
Lossless describes pixel reconstruction, not a promise that every save will have the same byte count.
Decide whether the artwork should be re-indexed
Re-indexing is worth testing for flat logos, small icons, charts, and graphics with few distinct colors. Create a delivery copy rather than replacing the editable master. Preserve required brand colors, thin lines, and transparent edges when building the palette. Do not judge success from the color-count setting alone; inspect the rendered result at normal size and under magnification on more than one background.
Photographic content, soft gradients, and complex translucent shadows may need truecolor. In those cases, keep the truecolor PNG or compare another delivery format such as WebP. A format change still requires controlled quality testing. Match dimensions, inspect alpha edges and small text, and measure bytes. Choose the smallest candidate that meets the visual requirement rather than the smallest output under any setting.
- Re-index graphics with genuinely limited colors
- Inspect gradients and translucent edges
- Compare alternatives under the same conditions
Palette optimization is useful for limited-color graphics, not a universal cure for every large PNG.
Validate the optimized copy in production
Keep a high-quality editing master and make optimization experiments on separate delivery copies. Record pixel dimensions, color type, color count, transparency mode, and bytes for the source, edited PNG, and candidate. Compare small type, thin strokes, brand colors, gradients, shadows, and semitransparent boundaries. If an automated tool is involved, preserve representative samples for regression testing after version or setting changes.
Place the candidate on the real page or application background. An alpha edge that looks acceptable on white may show a fringe on dark gray. Confirm the actual file served by the browser, not only the local export. For animated PNG, verify frames separately because a still-image path may not preserve animation. Replace the production asset only after appearance, format, dimensions, and size all pass.
When optimization is automated, establish thresholds that stop deployment if dimensions change, the palette unexpectedly expands, or the byte size increases sharply. Keep a test set containing a flat icon, tiny text, a gradient, a translucent shadow, and critical brand colors. Re-run it whenever the optimizer or its options change. File hashes can confirm that bytes changed, but they cannot explain whether the decoded appearance is acceptable, so retain a visual comparison step. Document the accepted color type and limits for each asset class. Roll back to the previous delivery file when a new optimizer result fails. Keep the failed candidate for diagnosis rather than overwriting the known-good asset. Record the optimizer version with every approved output.
- Keep the editing master separate
- Record structure and byte changes
- Test light and dark destination backgrounds
Optimization succeeds only when the delivered file is smaller enough and remains visually correct in context.
Key takeaways
- Indexed PNG uses a PLTE palette and per-pixel indexes to represent a limited set of colors efficiently.
- Editing can expand the image to RGB or RGBA, increasing size even when the visible change is small.
- Lossless storage does not mean that encoding structure or byte size must remain identical.
- Re-index only when the artwork and transparency can tolerate a limited palette without visible defects.
Frequently asked questions
What is an indexed PNG?
It stores a PLTE color palette and lets pixels refer to palette entries instead of storing full colors directly.
Why did changing one label make the file larger?
The editor may have expanded the entire image to RGB or RGBA and saved that truecolor result.
Can a lossless PNG change size after saving?
Yes. Lossless pixel reconstruction does not prevent changes in color type, filters, compression, or metadata.
Should every PNG be reduced to 256 colors?
No. Photos, gradients, and complex transparency can show banding, rough edges, or color shifts.
Will WebP always be smaller?
No. Compare equivalent dimensions and settings, then evaluate both visual quality and bytes.