On systems where file names customarily include an extension signifying file type, the extension ".png" is recommended for PNG files. Lowercase ".png" is preferred if file names are case-sensitive.
The Internet Assigned Numbers Authority (IANA) has registered "image/png" as the Internet Media Type for PNG [RFC-2045], [RFC-2048]. For robustness, decoders may choose to also support the interim media type "image/x-png" that was in use before registration was complete.
In the Apple Macintosh system, the following conventions are recommended:
PNG itself is strictly a single-image format. However, it may be necessary to store multiple images within one file; for example, this is needed to convert some GIF files. In the future, a multiple-image format based on PNG may be defined. Such a format will be considered a separate file format and will have a different signature. PNG-supporting applications may or may not choose to support the multiple-image format.
See Rationale: Why not these features?.
A PNG file or datastream is composed of a collection of explicitly typed "chunks". Chunks whose contents are defined by the specification could actually contain anything, including malicious code. But there is no known risk that such malicious code could be executed on the recipient's computer as a result of decoding the PNG image.
The possible security risks associated with private chunk types and future chunk types cannot be specified at this time. Security issues will be considered when evaluating chunks proposed for registration as public chunks. There is no additional security risk associated with unknown or unimplemented chunk types, because such chunks will be ignored, or at most be copied into another PNG file.
The tEXt and zTXt chunks contain keywords and data that is meant to be displayed as plain text. The iCCP, sPLT, and some public "extension" chunks contain keywords meant to be displayed as plain text. It is possible that if a decoder displays such text without filtering out control characters, especially the ESC (escape) character, certain systems or terminals could behave in undesirable and insecure ways. We recommend that decoders filter out control characters to avoid this risk; see Recommendations for Decoders: Text chunk processing.
Every chunk begins with a length field, making it easier to write decoders invulnerable to fraudulent chunks that attempt to overflow buffers. The CRC at the end of every chunk provides a robust defense against accidentally corrupted data. Also, the PNG signature bytes provide early detection of common file transmission errors.
A decoder that fails to check CRCs could be subject to data corruption. The only likely consequence of such corruption is incorrectly displayed pixels within the image. Worse things might happen if the CRC of the IHDR chunk is not checked and the width or height fields are corrupted. See Recommendations for Decoders: Error checking.
A poorly written decoder might be subject to buffer overflow, because
chunks can be extremely large, up to (2^31)-1 bytes long. But
properly written decoders will handle large chunks without difficulty.