User-uploaded PNGs still need limits and decoding safeguards. File size alone does not describe decoded memory cost or parser risk.
Compressed bytes are not decoded size
A relatively small file can declare large dimensions. Once decoded, a raster may require width × height × channels × bytes-per-sample plus working memory. Validate dimensions before allocating blindly.
Trust the parser, not the extension
Renaming a file to .png does not make it PNG. Verify the format using a maintained image library and reject malformed input. MIME headers supplied by a client are hints, not proof.
Set resource limits
Bound file bytes, pixel dimensions, total pixel count, decode time, frame count for animated content, and downstream transform work. Limits should reflect what your product actually needs.
Metadata can be large or unexpected
PNG is extensible and can carry ancillary chunks. A pipeline that only expects pixels should decide which metadata it preserves and should not allow unbounded auxiliary data to become an accidental storage channel.
Re-encoding is useful but not magical
Decoding and re-encoding through a trusted library can normalize many uploads and remove unwanted metadata, but the decoder itself still processes attacker-controlled bytes. Keep libraries patched and isolate expensive processing where appropriate.
Validate the business object too
A valid PNG may still be the wrong image: wrong dimensions, aspect ratio, transparency policy, animation, or content for the product. File-format validation is only one layer of upload validation.
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.
