REC-png.html
PNG (Portable Network Graphics) Specification
Version 1.0
W3C Recommendation 01-October-1996
Previous page
Next page
Table of contents
On systems where file names customarily include an extension
signifying file type, the extension ".png" is recommended for
PNG files. Lower case ".png" is preferred if file names are
case-sensitive.
The PNG authors intend to register "image/png" as the
Internet Media Type for PNG
[RFC-1521,
RFC-1590].
At the date of this
document, the media type registration process had not been completed.
It is recommended that implementations also recognize the interim
media type "image/x-png".
In the Apple Macintosh system, the following conventions are
recommended:
- The four-byte file type code for PNG files is "PNGf".
(This code has been registered with Apple for PNG files.)
The creator code will vary depending on the creating application.
- The contents of the data fork must be a PNG file exactly
as described in the rest of this specification.
- The contents of the resource fork are unspecified. It may
be empty or may contain application-dependent resources.
- When transferring a Macintosh PNG file to a non-Macintosh
system, only the data fork should be transferred.
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 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 data that is meant
to be displayed as plain text. It is possible that if the 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.
Because every chunk's length is available at its beginning, and because
every chunk has a CRC trailer, there is a very robust defense against
corrupted data and against fraudulent chunks that attempt to overflow
the decoder's buffers. 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.
Previous page
Next page
Table of contents