PNG

Portable Network Graphics is a raster-graphics file format that supports lossless data compression. PNG was developed as an improved, non-patented replacement for Graphics Interchange Format.
PNG supports palette-based images, grayscale images, and full-color non-palette-based RGB or RGBA images. The PNG working group designed the format for transferring images on the Internet, not for professional-quality print graphics; therefore, non-RGB color spaces such as CMYK are not supported. A PNG file contains a single image in an extensible structure of chunks, encoding the basic pixels and other information such as textual comments and integrity checks documented in RFC 2083.
PNG files have the ".png" file extension and the "image/png" MIME media type.
PNG was published as an informational RFC 2083 in March 1997 and as an ISO/IEC 15948 standard in 2004.

History and development

The motivation for creating the PNG format was the announcement on 28 December 1994 that implementations of the Graphics Interchange Format format would have to pay royalties to Unisys due to their patent of the Lempel–Ziv–Welch data compression algorithm used in GIF. This led to a flurry of criticism from Usenet users. One of them was Thomas Boutell, who on 4 January 1995 posted a precursory discussion thread on the Usenet newsgroup "comp.graphics" in which he devised a plan for a free alternative to GIF. Other users in that thread put forth many propositions that would later be part of the final file format. Oliver Fromme, author of the popular JPEG viewer QPEG, proposed the PING name, eventually becoming PNG, a recursive acronym meaning PING is not GIF, and also the.png extension. Other suggestions later implemented included the deflate compression algorithm and 24-bit color support, the lack of the latter in GIF also motivating the team to create their file format. The group would become known as the PNG Development Group, and as the discussion rapidly expanded, it later used a mailing list associated with a CompuServe forum.
The full specification of PNG was released under the approval of World Wide Web Consortium on 1 October 1996, and later as RFC 2083 on 15 January 1997. The specification was revised on 31 December 1998 as version 1.1, which addressed technical problems for gamma and color correction. Version 1.2, released on 11 August 1999, added the iTXt chunk as the specification's only change, and a reformatted version of 1.2 was released as a second edition of the W3C standard on 10 November 2003, and as an International Standard on 3 March 2004.
Although GIF allows for animation, it was initially decided that PNG should be a single-image format. In 2001, the developers of PNG published the Multiple-image Network Graphics format, with support for animation. MNG achieved moderate application support, but not enough among mainstream web browsers and no usage among web site designers or publishers. In 2008, certain Mozilla developers published the Animated Portable Network Graphics format with similar goals. APNG is a format that is natively supported by Gecko- and Presto-based web browsers and is also commonly used for thumbnails on Sony's PlayStation Portable system. In 2017, Chromium based browsers adopted APNG support. In January 2020, Microsoft Edge became Chromium based, thus inheriting support for APNG. With this all major browsers now support APNG.
The PNG Working Group has been chartered by the W3C, since September 14, 2021, to maintain and develop for the PNG specification. The third edition of PNG specification, which adds the proper support of APNG, high dynamic range and Exif data, was published as the first public working draft on October 25, 2022, and ultimately as a W3C Recommendation on June 24, 2025.

PNG Working Group

The original PNG specification was authored by an ad hoc group of computer graphics experts and enthusiasts. Discussions and decisions about the format were conducted by email. The original authors listed on RFC 2083 are:

Editor: Thomas Boutell
Contributing Editor: Tom Lane
Authors : Mark Adler, Thomas Boutell, Christian Brunschen, Adam M. Costello, Lee Daniel Crocker, Andreas Dilger, Oliver Fromme, Jean-loup Gailly, Chris Herborth, Aleks Jakulin, Neal Kettler, Tom Lane, Alexander Lehmann, Chris Lilley, Dave Martindale, Owen Mortensen, Keith S. Pickens, Robert P. Poole, Glenn Randers-Pehrson, Greg Roelofs, Willem van Schaik, Guy Schalnat, Paul Schmidt, Tim Wegner, Jeremy Wohl
File format

File header

A PNG file starts with an eight-byte signature :

Values	Purpose
`89`	Has the high bit set to detect transmission systems that do not support 8-bit data and to reduce the chance that a text file is mistakenly interpreted as a PNG, or vice versa.
`50 4E 47`	In ASCII, the letters PNG, allowing a person to identify the format easily if it is viewed in a text editor.
`0D 0A`	A DOS-style line ending to detect DOS-Unix line ending conversion of the data.
`1A`	A byte that stops display of the file under DOS when the command type has been used—the end-of-file character.
`0A`	A Unix-style line ending to detect Unix-DOS line ending conversion.

"Chunks" within the file

After the header, comes a series of chunks, each of which conveys certain information about the image. Chunks declare themselves as critical or ancillary, and a program encountering an ancillary chunk that it does not understand can safely ignore it. This chunk-based storage layer structure, similar in concept to a container format or to Amigas IFF, is designed to allow the PNG format to be extended while maintaining compatibility with older versions—it provides forward compatibility, and this same file structure is used in the associated MNG, JNG, and APNG formats.
A chunk consists of four parts: length, chunk type/name, chunk data and CRC. The CRC is a network-byte-order CRC-32 computed over the chunk type and chunk data, but not the length.

Length	Chunk type	Chunk data	CRC
4 bytes	4 bytes	Length bytes	4 bytes

Chunk types are given a four-letter case sensitive ASCII type/name; compare FourCC. The case of the different letters in the name is a bit field that provides the decoder with some information on the nature of chunks it does not recognize.
The case of the first letter indicates whether the chunk is critical or not. If the first letter is uppercase, the chunk is critical; if not, the chunk is ancillary. Critical chunks contain information that is necessary to read the file. If a decoder encounters a critical chunk it does not recognize, it must abort reading the file or supply the user with an appropriate warning.
The case of the second letter indicates whether the chunk is "public" or "private". Uppercase is public and lowercase is private. This ensures that public and private chunk names can never conflict with each other.
The third letter must be uppercase to conform to the PNG specification. It is reserved for future expansion. Decoders should treat a chunk with a lower case third letter the same as any other unrecognized chunk.
The case of the fourth letter indicates whether the chunk is safe to copy by editors that do not recognize it. If lowercase, the chunk may be safely copied regardless of the extent of modifications to the file. If uppercase, it may only be copied if the modifications have not touched any critical chunks.

Critical chunks

A decoder must be able to interpret critical chunks to read and render a PNG file.

IHDR must be the first chunk; it is 13 data bytes long and contains the image's
*width
*height
*bit depth
*color type
*compression method
*filter method
*interlace method.

As stated in the World Wide Web Consortium, bit depth is defined as "the number of bits per sample or per palette index ".

PLTE contains the palette: a list of colors.
IDAT contains the image, which may be split among multiple IDAT chunks. Such splitting slightly increases the file size, but makes it possible to generate a PNG in a streaming manner. The IDAT chunk contains the actual image data, which is the output stream of the compression algorithm.
IEND marks the image end; the data field of the IEND chunk has 0 bytes/is empty.

The PLTE chunk is essential for color type 3. It is optional for color types two and six and it must not appear for color types 0 and 4.

Ancillary chunks

Other image attributes that can be stored in PNG files include gamma values, background color, and textual metadata information. PNG also supports color management through the inclusion of ICC color profiles.

bKGD gives the default background color. It is intended for use when there is no better choice available, such as in standalone image viewers.
cHRM gives the chromaticity coordinates of the display primaries and white point.
cICP specifies the color space, transfer function and matrix coefficients as defined in ITU-T H.273. It is intended for use with HDR imagery without requiring a color profile.
dSIG is for storing digital signatures.
eXIf stores Exif metadata.
gAMA specifies gamma. The gAMA chunk contains only 4 bytes, and its value represents the gamma value multiplied by 100,000; for example, the gamma value 1/3.4 calculates to 29411.7647059 *) and is converted to an integer for storage.
hIST can store the histogram, or total amount of each color in the image.
iCCP is an ICC color profile.
iTXt contains a keyword and UTF-8 text, with encodings for possible compression and translations marked with language tag. The Extensible Metadata Platform uses this chunk with a keyword 'XML:com.adobe.xmp'
pHYs holds the intended pixel size ; the pHYs contains "Pixels per unit, X axis", "Pixels per unit, Y axis", and "Unit specifier" for a total of 9 bytes.
sBIT indicates the color-accuracy of the source data; this chunk contains a total of between 1 and 5 bytes, depending on the color type.
sPLT suggests a palette to use if the full range of colors is unavailable.
sRGB indicates that the standard sRGB color space is used; the sRGB chunk contains only 1 byte, which is used for "rendering intent".
sTER stereo-image indicator chunk for stereoscopic images.
tEXt can store text that can be represented in ISO/IEC 8859-1, with one key-value pair for each chunk. The "key" must be between one and 79 characters long. Separator is a null character. The "value" can be any length, including zero up to the maximum permissible chunk size minus the length of the keyword and separator. Neither "key" nor "value" can contain null character. Leading or trailing spaces are also disallowed.
tIME stores the time that the image was last changed.
tRNS contains transparency information. For indexed images, it stores alpha channel values for one or more palette entries. For truecolor and grayscale images, it stores a single pixel value that is to be regarded as fully transparent.
zTXt contains compressed text with the same limits as tEXt.