View source for Portable Network Graphics

{{Short description|Family of lossless compression file formats for image files}}
{{Update|date=October 2021|reason=in comparison to WebP and AVIF image formats}}
{{Use dmy dates|date=August 2014}}
{{Infobox file format
| name         = Portable Network Graphics 
| icon         = 
| screenshot   = <div style="background-color: #fff;
background-image: linear-gradient(45deg, #eee 25%, transparent 25%, transparent 75%, #eee 75%, #eee), 
linear-gradient(45deg, #eee 25%, transparent 25%, transparent 75%, #eee 75%, #eee);
background-size:20px 20px;
background-position:0 0, 10px 10px;
background-attachment: fixed;
width: -moz-fit-content;
width: -webkit-fit-content;
width: fit-content;
margin: 0 auto;">
[[File:PNG transparency demonstration 1.png|280px]]
</div>
| caption      = A PNG image with an 8-bit transparency channel, overlaid onto a checkered background, typically used in [[graphics software]] to indicate transparency
| extension    = .png
| mime         = image/png
| typecode     = PNGf<br />PNG
| uniform type = public.png
| conforms to  = public.image
| genre        = [[Lossless data compression|Lossless]] [[Raster graphics|bitmap]] [[Graphics file format|image format]]
| containerfor = 
| containedby  = 
| owner        = PNG Development Group (donated to [[World Wide Web Consortium|W3C]])
| released     = {{start date and age|df=yes|1996|10|1}}
| extendedfrom = 
| extendedto   = [[APNG]], [[JPEG Network Graphics|JNG]] and [[Multiple-image Network Graphics|MNG]]
| standard     = [[International Organization for Standardization|ISO]]/[[International Electrotechnical Commission|IEC]] [[List of ISO standards|15948]],<ref name="iso">{{Cite web|url=http://www.iso.org/iso/catalogue_detail.htm?csnumber=29581|title=ISO/IEC 15948:2004 – Information technology – Computer graphics and image processing – Portable Network Graphics (PNG): Functional specification|publisher=International Organization for Standardization|date=3 March 2004|access-date=2011-02-19}}</ref> [[Internet Engineering Task Force|IETF]] RFC 2083
| open          = Yes
| magic         = {{code|89 50 4e 47 0d 0a 1a 0a}} (8 bytes [[Hexadecimal]])
}}

'''Portable Network Graphics''' ('''PNG''', officially pronounced {{IPAc-en|p|ɪ|ŋ}}<ref name="pnghist">{{Cite web|url=http://www.libpng.org/pub/png/#history|title=History of PNG|last=Roelofs|first=Greg|publisher=[[libpng]]|date=29 May 2010|access-date=2010-10-20}}</ref>{{Sfn|W3C|2003|loc=[https://www.w3.org/TR/PNG/#1Scope 1 Scope]}} {{respell|PING}}, colloquially pronounced {{IPAc-en|ˌ|p|iː|ɛ|n|ˈ|dʒ|iː}}<ref>{{Cite web|url=https://www.oxfordlearnersdictionaries.com/definition/english/png|title=Definition of PNG noun from the Oxford Advanced Learner's Dictionary|website=Oxford Learner's Dictionaries|access-date=2018-01-21}}</ref> {{respell|PEE|en|JEE}}) is a raster-graphics file format that supports lossless data compression.<ref>{{Cite web |title=Portable Network Graphic .PNG File Description |url=https://surferhelp.goldensoftware.com/subsys/subsys_portable_network_graphic_file_description.htm |access-date=2022-08-12 |website=surferhelp.goldensoftware.com}}</ref> PNG was developed as an improved, non-patented replacement for [[Graphics Interchange Format]] (GIF) &mdash; unofficially, the initials PNG stood for the [[recursive acronym]] "PNG's not GIF".<ref>{{Cite web|title=Web Review: PNG's NOT GIF!|url=https://people.apache.org/~jim/NewArchitect/webrevu/1997/05_09/designers/05_09_97_1.html|access-date=2021-11-24|website=people.apache.org|first=Greg|last=Roelofs|archive-date=30 March 2022|archive-url=https://web.archive.org/web/20220330031000/https://people.apache.org/~jim/NewArchitect/webrevu/1997/05_09/designers/05_09_97_1.html|dead-url=yes}}</ref>

PNG supports palette-based images (with palettes of 24-bit [[RGB color model|RGB]] or 32-bit [[RGBA color space|RGBA]] colors), [[grayscale]] images (with or without an [[Alpha compositing|alpha channel]] for transparency), 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 space]]s such as [[CMYK color model|CMYK]] are not supported. A PNG file contains a single image in an extensible structure of ''chunks'', encoding the basic [[pixel]]s and other information such as textual comments and [[Integrity checker|integrity checks]] documented in [[Request for Comments|RFC]] 2083.<ref>{{cite journal|url= https://tools.ietf.org/html/rfc2083#section-3|title= PNG (Portable Network Graphics) Specification Version 1.0|at= sec. 3|journal= RFC 2083|publisher= [[Internet Engineering Steering Group|IESG]]<!-- non-IETF work approved by IESG, eventually published by the RFC editor like all RCs -->|doi= 10.17487/RFC2083|author1=T. Boutell|display-authors=etal|date= March 1997|doi-access= free}}</ref>

PNG files use the [[file extension]] <code>PNG</code> or <code>png</code> and have been assigned the [[MIME type|MIME]] media type <code>image/png</code>.<ref>{{Cite web|url=https://www.iana.org/assignments/media-types/image/png|title=Registration of new Media Type image/png|publisher=[[Internet Assigned Numbers Authority|IANA]]|date=1996-07-27}}</ref>
PNG was published as informational <nowiki>RFC 2083</nowiki> in March 1997 and as an [[ISO/IEC]] 15948 standard in 2004.<ref name="iso" />

== History and development ==
{{See also|Graphics Interchange Format#Unisys and LZW patent enforcement}}

The motivation for creating the PNG format was the realization that, on 28 December 1994, the [[Lempel–Ziv–Welch]] (LZW) [[data compression]] algorithm used in the Graphics Interchange Format (GIF) format was [[patent]]ed by [[Unisys]]. The patent required that all software supporting GIF pay royalties, leading 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''{{Citation needed|date=June 2022}}, and also the <code>.png</code> [[Filename extension|extension]]. Other suggestions later implemented included the [[Deflate|deflate compression algorithm]] and [[Color depth#True color (24-bit)|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.<ref name="pnghist"/>{{Sfn|Roelofs|1999|loc=Chapter 7. History of the Portable Network Graphics Format}}

The full specification of PNG was released under the approval of W3C 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 correction|gamma]] and [[color correction]]. Version 1.2, released on 11 August 1999, added the <code>iTXt</code> 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,<ref name="w3IHDR"/> and as an International Standard ([http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=29581&scopelist=PROGRAMME ISO/IEC 15948:2004]) on 3 March 2004.<ref>{{cite web|url=http://www.libpng.org/pub/png/spec/|title=Portable Network Graphics (PNG) Specification and Extensions|last=Roelofs|first=Greg|work=libpng|date=29 September 2011|access-date=August 15, 2021}}</ref><ref name="iso" />

Although GIF allows for [[computer animation|animation]], it was decided that PNG should be a single-image format.<ref>{{Cite web|title=PNG (Portable Network Graphics) Specification 1.0|url=https://tools.ietf.org/html/rfc2083#page-39|publisher=W3C|at=sec. 8.4|date=1 October 1996|quote=PNG itself is strictly a single-image format. (...) In the future, a multiple-image format based on PNG may be defined. Such a format will be considered a separate file format}}</ref> In 2001, the developers of PNG published the Multiple-image Network Graphics (MNG) 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]] (APNG) format with similar goals. APNG is a format that is natively supported by [[Gecko (software)|Gecko]]- and [[Presto (browser engine)|Presto]]-based web browsers and is also commonly used for thumbnails on Sony's [[PlayStation Portable]] system (using the normal PNG file extension). In 2017, Chromium based browsers adopted APNG support. In January 2020, [[Microsoft Edge]] became [[Chromium (web browser)|Chromium]] based, thus inheriting support for APNG. With this all major browsers now support APNG.

== 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:<ref name="rfc2083">{{Cite document|last=Boutell|first=Thomas|date=1 October 1996|title=PNG (Portable Network Graphics) Specification 1.0|url=http://tools.ietf.org/html/rfc2083}}</ref>
*Editor: [[Thomas Boutell]]
*Contributing Editor: [[Tom Lane (computer scientist)|Tom Lane]]
*Authors (in alphabetical order by last name): [[Mark Adler]], Thomas Boutell, [[Christian Brunschen]], [[Adam M. Costello]], [[Lee Daniel Crocker]], [[Andreas Dilger]], [[Oliver Fromme]], [[Jean-loup Gailly]]<!--Person prefers lowercase l (ell), see his article-->, [[Chris Herborth]], [[Aleks Jakulin]], [[Neal Kettler]], Tom Lane, [[Alexander Lehmann]], [[Chris Lilley (computer scientist)|Chris Lilley]], Dave Martindale, [[Owen Mortensen]], [[Keith S. Pickens]], [[Robert P. Poole]], [[Glenn Randers-Pehrson]], [[Greg Roelofs]], Willem van Schaik, [[Guy Schalnat]], [[Paul Schmidt (computer programmer)|Paul Schmidt]], [[Tim Wegner]], [[Jeremy Wohl]]

==File format==
[[File:PNG-Gradient hex.png|thumb|The PNG image [[File:PNG-Gradient.png|30px]] viewed with a [[hex editor]] application for [[Ubuntu OS|Ubuntu]].]]

=== File header ===
A PNG file starts with an 8-[[byte]] [[Binary signature|signature]]{{Sfn|W3C|2003|loc=[https://www.w3.org/TR/PNG/#5PNG-file-signature 5.2 PNG signature]}} (refer to hex editor image on the right):

{|class=wikitable
! style="text-align:left; background:#def;"|Values (hex)
! style="text-align:left; background:#def;"|Purpose
|-
|<code>89</code>
|Has the high bit set to detect transmission systems that do not support [[8-bit clean|8-bit data]] and to reduce the chance that a text file is mistakenly interpreted as a PNG, or vice versa.
|-
|<code>50&nbsp;4E&nbsp;47</code>
|In [[ASCII]], the letters ''PNG'', allowing a person to identify the format easily if it is viewed in a text editor.
|-
|<code>0D 0A</code>
|A [[DOS]]-style [[newline|line ending]] (CRLF) to detect DOS-Unix line ending conversion of the data.
|-
|<code>1A</code>
|A byte that stops display of the file under DOS when the command [[TYPE (DOS command)|type]] has been used—the [[end-of-file]] character.
|-
|<code>0A</code>
|A Unix-style line ending (LF) to detect Unix-DOS line ending conversion.
|}

=== "Chunks" within the file ===
After the header, comes a series of [[Chunk (information)|chunks]],{{Sfn|W3C|2003|loc=[https://www.w3.org/TR/PNG/#5Chunk-layout 5.3 Chunk layout]}} 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 (digital)|container format]] or to [[Amiga]]{{'}}s [[Interchange File Format|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 (with different signature and chunks) is used in the associated [[MNG]], JNG, and APNG formats.

A chunk consists of four parts: length (4 bytes,<ref name="PoCorGTFO">{{Cite book|url=https://books.google.com/books?id=lvMxDwAAQBAJ&pg=PT686|title=PoC or GTFO|isbn=9781593278984|quote=Each chunk consists of four parts: Length, a Chunk Type, the Chunk Data, and a 32-bit CRC. The Length is a 32-bit unsigned integer indicating the size of only the Chunk Data field|last1=Laphroaig|first1=Manul|date=31 October 2017}}</ref> [[Endianness#Big-endian|big-endian]]), chunk type/name (4 bytes<ref>{{Cite book |url=https://books.google.com/books?id=lvMxDwAAQBAJ&pg=PT686 - |quote=Chunk Type is a 32-bit FourCC code such as IHDR, IDAT, or IEND.|title=PoC or GTFO|isbn=9781593278984|last1=Laphroaig|first1=Manul|date=31 October 2017}}</ref>), chunk data (length bytes) and [[cyclic redundancy check|CRC]] (cyclic redundancy code/checksum; 4 bytes<ref name="PoCorGTFO" />). The CRC is a network-byte-order [[Computation of cyclic redundancy checks|CRC-32]] computed over the chunk type and chunk data, but not the length.

{| class="wikitable" style="text-align: center;"
|-
! style="width: 8em" | Length
! style="width: 8em" | Chunk type
! style="width: 16em"| Chunk data
! style="width: 8em" | CRC
|-
| 4 bytes
| 4 bytes
| ''Length'' bytes
| 4 bytes
|}

Chunk types are given a four-letter [[Case sensitivity|case sensitive]] ASCII type/name; compare [[FourCC]]. The case of the different letters in the name (bit 5 of the numeric value of the character) is a [[bit field]] that provides the [[Codec|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" (either in the specification or the registry of special-purpose public chunks) or "private" (not standardised). Uppercase is public and lowercase is private. This ensures that public and private chunk names can never conflict with each other (although two private chunk names could conflict).

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 unrecognised 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.
* <code>IHDR</code> must be the first chunk; it contains (in this order) the image's
**width (4 bytes)
**height (4 bytes)
**bit depth (1 byte, values 1, 2, 4, 8, or 16)
**color type (1 byte, values 0, 2, 3, 4, or 6)
**compression method (1 byte, value 0)
**filter method (1 byte, value 0)
**interlace method (1 byte, values 0 "no interlace" or 1 "[[Adam7]] interlace") (13 data bytes total).<ref name="w3IHDR">{{Harvnb|W3C|2003|loc=[https://www.w3.org/TR/PNG/#11IHDR 11.2.2 <code>IHDR</code> Image header]}}</ref>
As stated in the World Wide Web Consortium, bit depth is defined as "the number of bits per sample or per palette index (not per pixel)".<ref name="w3IHDR"/>
* <code>PLTE</code> contains the [[Palette (computing)|palette]]: a list of colors.
* <code>IDAT</code> contains the image, which may be split among multiple IDAT chunks. Such splitting increases filesize slightly, 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.{{Sfn|W3C|2003|loc=[https://www.w3.org/TR/PNG/#11IDAT 11.2.4 <code>IDAT</code> Image data]}}
* <code>IEND</code> marks the image end; the data field of the IEND chunk has 0 bytes/is empty.{{Sfn|W3C|2003|loc=[https://www.w3.org/TR/PNG/#11IEND 11.2.5 <code>IEND</code> Image trailer]}}
The <code>PLTE</code> chunk is essential for color type 3 (indexed color). It is optional for color types 2 and 6 (truecolor and truecolor with alpha) and it must not appear for color types 0 and 4 (grayscale and grayscale with alpha).

==== 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 profile|ICC color profiles]].{{Sfn|W3C|2003|loc=[https://www.w3.org/TR/PNG/#11iCCP 11.3.3.3 <code>iCCP</code> Embedded ICC profile]}}

* <code>bKGD</code> gives the default background color. It is intended for use when there is no better choice available, such as in standalone image viewers (but not web browsers; see below for more details).
* <code>cHRM</code> gives the [[chromaticity]] coordinates of the display [[Primary color|primaries]] and [[white point]].
* <code>dSIG</code> is for storing digital signatures.<ref>{{Cite web|last=Thomas Kopp|date=17 April 2008|title=PNG Digital Signatures: Extension Specification|url=http://libpng.download/documents/signatures/}}</ref>
* <code>eXIf</code> stores [[Exif]] metadata.<ref>{{Cite web|url=http://ftp-osl.osuosl.org/pub/libpng/documents/pngext-1.5.0.html|title=Extensions to the PNG 1.2 Specification, version 1.5.0|website=ftp-osl.osuosl.org}}</ref>
* <code>gAMA</code> 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 ((1/3.4)*(100,000)) and is converted to an integer (29412) for storage.{{Sfn|W3C|2003|loc=[https://www.w3.org/TR/PNG/#11gAMA 11.3.3.2 <code>gAMA</code> Image gamma]}}
* <code>hIST</code> can store the histogram, or total amount of each color in the image.
* <code>iCCP</code> is an [[ICC color profile]].
* <code>iTXt</code> contains a keyword and [[UTF-8]] text, with encodings for possible compression and translations marked with [[IETF language tag|language tag]]. The [[Extensible Metadata Platform]] (XMP) uses this chunk with a keyword 'XML:com.adobe.xmp'
* <code>pHYs</code> holds the intended pixel size (or pixel aspect ratio); the pHYs contains "Pixels per unit, X axis" (4 bytes), "Pixels per unit, Y axis" (4 bytes), and "Unit specifier" (1 byte) for a total of 9 bytes.{{Sfn|W3C|2003|loc=[https://www.w3.org/TR/PNG/#11pHYs 11.3.5.3 <code>pHYs</code> Physical pixel dimensions]}}
* <code>sBIT</code> (significant bits) indicates the color-accuracy of the source data; this chunk contains a total of between 1 and 5 bytes, depending on the color type.{{Sfn|W3C|2003|loc=[https://www.w3.org/TR/PNG/#11sBIT 11.3.3.4 <code>sBIT</code> Significant bits]}}<ref>{{cite web |url=https://www.w3.org/TR/PNG-Chunks.html |title=PNG (Portable Network Graphics) Specification \ Version 1.0 |website=w3.org |access-date=30 May 2022}} 4.2.6. sBIT Significant bits, 13 bytes total - color type 2 and 3 totaled 6 bytes</ref>{{Sfn|Roelofs|2003|loc=[http://www.libpng.org/pub/png/book/chapter11.html#png.ch11.div.7 Significant Bits (sBIT)]|postscript="Grayscale images are the simplest; sBIT then contains a single byte indicating the number of significant bits in the source data"}}
* <code>sPLT</code> suggests a palette to use if the full range of colors is unavailable.
* <code>sRGB</code> indicates that the standard [[sRGB color space]] is used; the sRGB chunk contains only 1 byte, which is used for "rendering intent" (4 values&mdash;0, 1, 2, and 3&mdash;are defined for rendering intent).<ref>{{Cite web|url=http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html#C.sRGB|title = PNG Specification: Chunk Specifications}}</ref>
* <code>sTER</code> stereo-image indicator chunk for [[stereoscopic]] images.<ref>{{Cite web|title=PNG News from 2006|url=http://www.libpng.org/pub/png/png2006.html|publisher=Libpng.org}}</ref>
* <code>tEXt</code> can store text that can be represented in [[ISO/IEC 8859-1]], with one [[Attribute–value pair|key-value]] pair for each chunk. The "key" must be between 1 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.
* <code>tIME</code> stores the time that the image was last changed.
* <code>tRNS</code> 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.
* <code>zTXt</code> contains compressed text (and a compression method marker) with the same limits as <code>tEXt</code>.

The lowercase first letter in these chunks indicates that they are not needed for the PNG specification. The lowercase last letter in some chunks indicates that they are safe to copy, even if the application concerned does not understand them.

=== Pixel format ===

{| class="wikitable floatright"
|+ PNG color type<ref name="w3IHDR"/>
! rowspan=2| Color type
! rowspan=2| Channels
! colspan=5| Bits per channel
|-
! 1 !! 2 !! 4 !! 8 !! 16
|-
! Indexed
! 1
| {{yes|1}}|| {{yes|2}}|| {{yes|4}}|| {{yes|8}}|| {{no|}}
|-
! Grayscale
! 1
| {{yes|1}}|| {{yes|2}}|| {{yes|4}}|| {{yes|8}}|| {{yes|16}}
|-
! Grayscale and alpha
! 2
| {{no| }}|| {{no| }}|| {{no| }}|| {{yes|16}}|| {{yes|32}}
|-
! Truecolor
! 3
| {{no| }}|| {{no| }}|| {{no| }}|| {{yes|24}}|| {{yes|48}}
|-
! Truecolor and alpha
! 4
| {{no| }}|| {{no| }}|| {{no| }}|| {{yes|32}}|| {{yes|64}}
|}

Pixels in PNG images are numbers that may be either indices of sample data in the palette or the sample data itself. The palette is a separate table contained in the PLTE chunk. Sample data for a single pixel consists of a tuple of between one and four numbers. Whether the pixel data represents palette indices or explicit sample values, the numbers are referred to as [[Channel (digital image)|channels]] and every number in the image is encoded with an identical format.

The permitted formats encode each number as an unsigned integer value using a fixed number of bits, referred to in the PNG specification as the ''bit depth''. Notice that this is not the same as color depth, which is commonly used to refer to the total number of bits in each pixel, not each channel. The permitted bit depths are summarized in the table along with the total number of bits used for each pixel.

The number of channels depends on whether the image is grayscale or color and whether it has an [[alpha channel]]. PNG allows the following combinations of channels, called the ''color type''.
[[File:PNG color depth comparison.png|thumb|upright=1.5|A demonstration of the colour depth in a PNG file, in bits per channel. Left: 8 bits, Right: 16 bits. Note the [[Digital artifact|artifacts]], adjusted contrast for clarity.]]
{| class=wikitable
|-
|0 (000<sub>2</sub>)|| grayscale
|-
|2 (010<sub>2</sub>)|| red, green and blue: rgb/truecolor
|-
|3 (011<sub>2</sub>)|| indexed: channel containing indices into a palette of colors
|-
|4 (100<sub>2</sub>)|| grayscale and alpha: level of [[Opacity (optics)|opacity]] for each pixel
|-
|6 (110<sub>2</sub>)|| red, green, blue and alpha
|}

The color type is specified as an 8-bit value however only the low 3 bits are used and, even then, only the five combinations listed above are permitted. So long as the color type is valid it can be considered as a bit field as summarized in the adjacent table:
{| class="wikitable floatright"
|+ PNG color types
!rowspan=2| Color<br /> type
!rowspan=2| Name
!colspan=4| Binary
!rowspan=2| Masks
|-
!title="undefined"| &nbsp; !!title="alpha"| A !!title="color"| C !!title="palette"| P
|-
! 0 !! Grayscale
| {{no|0}}||{{no|0}}||{{no|0}}||{{no|0}}
| &nbsp;
|-
! 2 !! Truecolor
| {{no|0}}||{{no|0}}||{{yes|1}}||{{no|0}}
| color
|-
! 3 !! Indexed
| {{no|0}}||{{no|0}}||{{yes|1}}||{{yes|1}}
| color, palette
|-
! 4 !! Grayscale and alpha
| {{no|0}}||{{yes|1}}||{{no|0}}||{{no|0}}
| alpha
|-
! 6 !! Truecolor and alpha
| {{no|0}}|| {{yes|1}}|| {{yes|1}}|| {{no|0}}
| alpha, color
|}

* bit value 1: the image data stores palette indices. This is only valid in combination with bit value 2;
* bit value 2: the image samples contain three channels of data encoding [[Trichromacy|trichromatic]] [[color]]s, otherwise the image samples contain one channel of data encoding [[relative luminance]],
* bit value 4: the image samples also contain an alpha channel expressed as a linear measure of the opacity of the pixel. This is not valid in combination with bit value 1.

With indexed color images, the palette always stores trichromatic colors at a depth of 8 bits per channel (24 bits per palette entry). Additionally, an optional list of 8-bit alpha values for the palette entries may be included; if not included, or if shorter than the palette, the remaining palette entries are assumed to be opaque. The palette must not have more entries than the image bit depth allows for, but it may have fewer (for example, if an image with 8-bit pixels only uses 90 colors then it does not need palette entries for all 256 colors). The palette must contain entries for all the pixel values present in the image.

The standard allows indexed color PNGs to have 1, 2, 4 or 8 bits per pixel; grayscale images with no alpha channel may have 1, 2, 4, 8 or 16 bits per pixel. Everything else uses a bit depth per channel of either 8 or 16. The combinations this allows are given in the table above. The standard requires that decoders can read all supported color formats, but many image editors can only produce a small subset of them.

=== Transparency of image ===
PNG offers a variety of transparency options. With true-color and grayscale images either a single pixel value can be declared as transparent or an alpha channel can be added (enabling any percentage of partial transparency to be used). For paletted images, alpha values can be added to palette entries. The number of such values stored may be less than the total number of palette entries, in which case the remaining entries are considered fully opaque.

The scanning of pixel values for binary transparency is supposed to be performed before any color reduction to avoid pixels becoming unintentionally transparent. This is most likely to pose an issue for systems that can decode 16-bits-per-channel images (as is required for compliance with the specification) but only output at 8 bits per channel (the norm for all but the highest end systems).

Alpha ''storage'' can be "associated" ("premultiplied") or "unassociated", but PNG standardized<ref name="w3.org">{{cite web|url=http://www.w3.org/TR/PNG-Rationale.html|title=PNG Specification: Rationale|work=w3.org}}</ref> on "unassociated" ("non-premultiplied") alpha, which means that imagery is not alpha ''encoded''; the emissions represented in RGB are not the emissions at the pixel level. This means that the over operation will multiply the RGB emissions by the alpha, and cannot represent emission and occlusion properly.

=== Compression ===
[[File:PNG demo Banana.png|thumb|250px|Example with several types of image content]][[File:PNG demo heatmap Banana.png|thumb|251px|Representation of bit cost per pixel for above PNG file (red=expensive, blue=cheap)]]
PNG uses a 2-stage compression process:
* pre-compression: filtering (prediction)
* compression: [[DEFLATE]]

PNG uses DEFLATE, a non-patented lossless data compression [[algorithm]] involving a combination of [[LZ77 and LZ78|LZ77]] and [[Huffman coding]]. [[Permissive software licence|Permissively-licensed]] DEFLATE implementations, such as [[zlib]], are widely available.

Compared to formats with [[lossy compression]] such as JPEG, choosing a compression setting higher than average delays processing, but often does not result in a significantly smaller file size.

==== Filtering ====
[[File:Pixel-prediction.svg|thumb|128px|PNG's filter method 0 can use the data in pixels A, B, and C to predict the value for X.]]
[[File:PNG-Gradient.png|thumb|128px|A PNG with 256 colors, which is only 251 bytes large with pre-filter. The same image as a GIF would be more than thirteen times larger.]]

Before DEFLATE is applied, the data is transformed via a prediction method: a single ''filter method'' is used for the entire image, while for each image line, a ''filter type'' is chosen to transform the data to make it more efficiently compressible.{{Sfn|W3C|2003|loc=[https://www.w3.org/TR/PNG/#9Filters 9 Filtering]}} The filter type used for a scanline is prepended to the scanline to enable inline decompression.

There is only one filter method in the current PNG specification (denoted method 0), and thus in practice the only choice is which filter type to apply to each line. For this method, the filter predicts the value of each pixel based on the values of previous neighboring pixels, and subtracts the predicted color of the pixel from the actual value, as in [[DPCM]]. An image line filtered in this way is often more compressible than the raw image line would be, especially if it is similar to the line above, since the differences from prediction will generally be clustered around 0, rather than spread over all possible image values. This is particularly important in relating separate rows, since DEFLATE has no understanding that an image is a 2D entity, and instead just sees the image data as a stream of bytes.

There are five filter types for filter method 0; each type predicts the value of each byte (of the image data before filtering) based on the corresponding byte of the pixel to the left (''A''), the pixel above (''B''), and the pixel above and to the left (''C'') or some combination thereof, and encodes the ''difference'' between the predicted value and the actual value. Filters are applied to byte values, not pixels; pixel values may be one or two bytes, or several values per byte, but never cross byte boundaries. The filter types are:<ref>{{cite web| url = http://www.libpng.org/pub/png/spec/1.2/PNG-Filters.html| work = PNG Specification| title = Filter Algorithms}}</ref>

{| class="wikitable"
|-
! Type byte !! Filter name !! Predicted value
|-
| 0|| None|| Zero (so that the raw byte value passes through unaltered)
|-
| 1|| Sub|| Byte ''A'' (to the left)
|-
| 2|| Up|| Byte ''B'' (above)
|-
| 3|| Average|| Mean of bytes ''A'' and ''B'', rounded down
|-
| 4|| Paeth|| ''A'', ''B'', or ''C'', whichever is closest to {{nowrap|1=''p'' = ''A'' + ''B'' − ''C''}}
|}
The Paeth filter is based on an algorithm by [[Alan W. Paeth]].<ref>{{cite journal|last1=Paeth|first1=Alan W.|title=Image File Compression Made Easy|journal=Graphics Gems 2|editor-last=Arvo|editor-first=James|publisher=Academic Press, San Diego|date=1991|pages=93–100|doi=10.1016/B978-0-08-050754-5.50029-3|isbn=0-12-064480-0}} {{closed access}}</ref>
Compare to the version of DPCM used in [[lossless JPEG]], and to the [[discrete wavelet transform]] using 1×2, 2×1, or (for the Paeth predictor) 2×2 windows and [[Haar wavelet]]s.

Compression is further improved by choosing filter types adaptively on a line-by-line basis. This improvement, and a heuristic method of implementing it commonly used by PNG-writing software, were created by Lee Daniel Crocker, who tested the methods on many images during the creation of the format;<ref>{{cite journal| url = http://www.ddj.com/architect/184409587?pgno=4| title = PNG: The Portable Network Graphic Format| journal = [[Dr. Dobb's Journal]]| issue = 232|date=July 1995| volume = 20| pages = 36–44| first = Lee Daniel| last = Crocker| author-link = Lee Daniel Crocker}}</ref> the choice of filter is a component of file size optimization, as discussed below.

If interlacing is used, each stage of the interlacing is filtered separately, meaning that the image can be progressively rendered as each stage is received; however, interlacing generally makes compression less effective.

=== Interlacing ===
[[File:Adam7 passes.gif|thumb|An illustration of Adam7 interlacing over a 16×16 image.]]
PNG offers an optional 2-dimensional, 7-pass [[interlacing (bitmaps)|interlacing]] scheme—the [[Adam7 algorithm]]. This is more sophisticated than GIF's 1-dimensional, 4-pass scheme, and allows a clearer low-resolution image to be visible earlier in the transfer, particularly if interpolation algorithms such as [[bicubic interpolation]] are used.<ref>{{cite web|url=http://nuwen.net/png.html|title=Introduction to PNG|publisher=nuwen.net|access-date=2010-10-20}}</ref>

However, the 7-pass scheme tends to reduce the data's compressibility more than simpler schemes.

=== Animation ===
[[File:Animated PNG example bouncing beach ball.png|thumb|An APNG (animated PNG) file (displays as static image in [[Comparison of web browsers#Image format support|some web browsers]])]]
PNG itself does not support animation. MNG is an extension to PNG that does; it was designed by members of the PNG Group. MNG shares PNG's basic structure and chunks, but it is significantly more complex and has a different file signature, which automatically renders it incompatible with standard PNG decoders. This means that most web browsers and applications either never supported MNG or dropped support for it.

The complexity of MNG led to the proposal of APNG by developers at the Mozilla Foundation. It is based on PNG, supports animation and is simpler than MNG. APNG offers fallback to single-image display for PNG decoders that do not support APNG. Today, the APNG format is supported by all major web browsers.<ref name=":0">{{Cite web|title=Can I use... Support tables for HTML5, CSS3, etc|url=https://caniuse.com/apng|access-date=2021-02-06|website=caniuse.com}}</ref> APNG is supported in [[Mozilla Firefox|Firefox]] 3.0 and up, [[Pale Moon (web browser)|Pale Moon]] (all versions), and [[Safari (web browser)|Safari]] 8.0 and up.<ref>{{cite web |date=2014-09-17 |title=iOS 8 and iPhone 6 for web developers and designers: next evolution for Safari and native webapps |url=http://www.mobilexweb.com/blog/safari-ios8-iphone6-web-developers-designers |access-date=2014-09-24 |publisher=mobilexweb.com}}</ref> Chromium 59.0 added APNG support,<ref>{{cite web|url = https://chromium.googlesource.com/chromium/src/+/7d2b8c45afc9c0230410011293cc2e1dbb8943a7|title = chromium / chromium / src / 7d2b8c45afc9c0230410011293cc2e1dbb8943a7|access-date = 31 March 2017|author=scroggo|work = chromium.googlesource.com|date = 14 March 2017}}</ref><ref>{{cite web|url = https://chromium.googlesource.com/chromium/src/+log/59.0.3047.0..59.0.3053.0?pretty=fuller&n=10000|title = chromium / chromium / src / 59.0.3047.0..59.0.3053.0|access-date = 31 March 2017|author=chrome-cron|display-authors=etal|work = chromium.googlesource.com|date = 27 March 2017}}</ref> followed by Google Chrome. [[Opera (web browser)|Opera]] supported APNG in versions 10–12.1, but support lapsed in version 15 when it switched to the [[Blink (browser engine)|Blink]] rendering engine; support was re-added in Opera 46 (inherited from Chromium 59).<ref>{{Cite web |title=Dev.Opera — What’s new in Chromium 59 and Opera 46 |url=https://dev.opera.com/blog/opera-46/ |access-date=2022-09-11 |website=dev.opera.com}}</ref> Microsoft Edge has supported APNG since version 79.0, when it switched to a Chromium-based engine.

The PNG Group decided in April 2007 not to embrace APNG.<ref>{{cite web|url=http://sourceforge.net/mailarchive/message.php?msg_name=3.0.6.32.20070420132821.012dd8e8%40mail.comcast.net|title=Vote failed: APNG 20070405a|date=20 April 2007|url-status=dead|archive-url=https://web.archive.org/web/20080203042347/http://sourceforge.net/mailarchive/message.php?msg_name=3.0.6.32.20070420132821.012dd8e8%40mail.comcast.net|archive-date=3 February 2008 }}</ref> Several alternatives were under discussion, including ANG, aNIM/mPNG, "PNG in GIF" and its subset "RGBA in GIF".<ref>{{cite web|url=http://gjuyn.xs4all.nl/pnganim.html|archive-url=https://web.archive.org/web/20090124013928/http://gjuyn.xs4all.nl/pnganim.html|title=PNG Group animation proposal comparison + test-software|archive-date=24 January 2009|work=xs4all.nl}}</ref> However, currently only APNG has widespread support.

=== Examples ===
{| class="wikitable" style="text-align: center;"
|+ Structure of a very simple PNG file
|-
| style="width: 20em"| {{code|89 50 4E 47 0D 0A 1A 0A}}<br />PNG signature
| style="width: 14em"| {{code|IHDR}}<br />Image header
| style="width: 26em"| {{code|IDAT}}<br />Image data
| style="width: 14em"| {{code|IEND}}<br />Image end
|}

{| class="wikitable"
|+ Contents of a minimal PNG file representing one red pixel
|-
! scope="col"|Hex
! scope="col"|As characters
|-
| style="font-family: Consolas, Andale Mono, Courier New, monospace"|
<span style="background:#fcc;">89 50 4E 47 0D 0A 1A 0A </span><span style="background:#cfc;">00 00 00 0D 49 48 44 52</span><br />
<span style="background:#cfc;">00 00 00 01 00 00 00 01 08 02 00 00 00 90 77 53</span><br />
<span style="background:#cfc;">DE </span><span style="background:#ccf;">00 00 00 0C 49 44 41 54 08 D7 63 F8 CF C0 00</span><br />
<span style="background:#ccf;">00 03 01 01 00 18 DD 8D B0 </span><span style="background:#fec;">00 00 00 00 49 45 4E</span><br />
<span style="background:#fec;">44 AE 42 60 82</span>
| style="font-family: Consolas, Andale Mono, Courier New, monospace"|
<span style="background:#fcc;">.PNG....</span><span style="background:#cfc;">....IHDR</span><br />
<span style="background:#cfc;">..............wS</span><br />
<span style="background:#cfc;">.</span><span style="background:#ccf;">....IDAT..c....</span><br />
<span style="background:#ccf;">.........</span><span style="background:#fec;">....IEN</span><br />
<span style="background:#fec;">D.B`.</span>
|}
{| class="wikitable"
|+IHDR Chunk
!Offset into chunk
!Hex Value
!Decimal Value
!Text
!Meaning
|-
|0
|0x0D
|13
|
|IHDR chunk has 13 bytes of content
|-
|4
|0x49484452
|
|IHDR
|Identifies a Header chunk
|-
|8
|0x01
|1
|
|Image is 1 pixel wide
|-
|12
|0x01
|1
|
|Image is 1 pixel high
|-
|16
|0x08
|8
|
|8 bits per pixel (per channel)
|-
|17
|0x02
|2
|
|Color type 2 (RGB/truecolor)
|-
|18
|0x00
|0
|
|Compression method 0 (only accepted value)
|-
|19
|0x00
|0
|
|Filter method 0 (only accepted value)
|-
|20
|0x00
|0
|
|Not interlaced
|-
|21
|0x907753DE
|
|
|CRC of chunk's type and content (but not length)
|}
{| class="wikitable"
|+IDAT Chunk
!Offset  into chunk
!Hex Value
!Meaning
|-
|0
|0x0C
|IDAT chunk has  12 bytes of content
|-
|4
|0x49444154
|Identifies a Data chunk
|-
|8
|0x08
|DEFLATE compression method using a 256-byte window<ref name=":1">{{Cite journal|title=rfc1950|url=https://datatracker.ietf.org/doc/html/rfc1950#page-4|access-date=2021-08-18|website=datatracker.ietf.org|date=May 1996|last1=Deutsch|first1=L. Peter|last2=Gailly|first2=Jean-Loup}}</ref>
|-
|9
|0xD7
|ZLIB FCHECK value, no dictionary used, maximum compression algorithm<ref name=":1" />
|-
|10
|0x63F8CFC00000
|A compressed DEFLATE block using the static Huffman code that decodes to 0x00 0xFF 0x00 0x00<ref>{{Cite journal|title=rfc1951|url=https://datatracker.ietf.org/doc/html/rfc1951#page-3|access-date=2021-08-18|website=datatracker.ietf.org|date=May 1996|last1=Deutsch|first1=L. Peter}}</ref>
|-
|16
|0x03010100
|The ZLIB check value: the Adler32 checksum of the uncompressed data<ref name=":1" />
|-
|20
|0x18DD8DB0
|CRC of chunk's type and content (but not length)
|}
Displayed in the fashion of hex editors, with on the left side byte values shown in hex format, and on the right side their equivalent characters from [[ISO-8859-1]] with unrecognized and control characters replaced with periods. Additionally the PNG signature and individual chunks are marked with colors. Note they are easy to identify because of their human readable type names (in this example PNG, IHDR, IDAT, and IEND).

== Advantages ==
Reasons to use this International Standard may be:
*'''Portability''': Transmission is independent of the software and hardware platform.
*'''Completeness''': it's possible to represent truecolor, indexed-color, and greyscale images.
*'''Coding and decoding in series''': allows to generate and read data streams in series, that is, the format of the data stream is used for the generation and visualization of images at the moment through serial communication.
*'''Progressive presentation''': to be able to transmit data flows that are initially an approximation of the entire image and progressively they improve as the data flow is received.
*'''Soundness to transmission errors''': detects the transmission errors of the data stream correctly.
*'''Losslessness''': No loss: filtering and compression preserve all information.
*'''Efficiency''': any progressive image presentation, compression and filtering seeks efficient decoding and presentation.
*'''Compression''': images can be compressed efficiently and consistently.
*'''Easiness''': the implementation of the standard is easy.
*'''Interchangeability''': any PNG decoder that follows the standards can read all PNG data streams.
*'''Flexibility''': allows future extensions and private additions without affecting the previous point.
*'''Freedom of legal restrictions''': the algorithms used are free and accessible.

== Comparison with other file formats ==
{{Main|Comparison of graphics file formats}}

=== Graphics Interchange Format (GIF) ===
* On small images, [[GIF]] can achieve greater compression than PNG (see the [[#File size and optimization software|section on filesize]], below).
* On most images, except for the above case, a GIF file has a larger size than an indexed PNG image.
* PNG gives a much wider range of transparency options than GIF, including alpha channel transparency.
* Whereas GIF is limited to 8-bit [[indexed color]], PNG gives a much wider range of color depths, including 24-bit (8 bits per channel) and 48-bit (16 bits per channel) [[24-bit color|truecolor]], allowing for greater color precision, smoother fades, etc.<ref>{{cite web|url=http://www.libpng.org/pub/png/pngintro.html|title=A Basic Introduction to PNG Features|publisher=Libpng.org|access-date=2010-10-20}}</ref> When an alpha channel is added, up to 64 bits per pixel (before compression) are possible.
* When converting an image from the PNG format to GIF, the image quality may suffer due to [[posterization]] if the PNG image has more than 256 colors.
* GIF intrinsically supports animated images. PNG supports animation only via unofficial extensions (see the [[#Animation|section on animation]], above).

PNG images are less widely supported by older browsers. In particular, IE6 has limited support for PNG.<ref>{{cite web|url=http://www.sitepoint.com/gif-png-jpg-which-one-to-use/|title=GIF, PNG, JPG. Which One To Use?|publisher=Sitepoint.com|date=3 August 2009|access-date=2010-10-20}}</ref>

=== JPEG ===
[[File:Comparison of JPEG and PNG.png|thumb|200px|left|Composite image comparing lossy compression in JPEG with lossless compression in PNG: the JPEG artifacts can be easily visible in the background of this kind of image data, where the PNG image has solid color.]]

The JPEG (Joint Photographic Experts Group) format can produce a smaller file than PNG for [[photography|photographic]] (and photo-like) images, since JPEG uses a lossy encoding method specifically designed for photographic image data, which is typically dominated by soft, low-contrast transitions, and an amount of noise or similar irregular structures. Using PNG instead of a high-quality JPEG for such images would result in a large increase in filesize with [[transparency (data compression)|negligible]] gain in quality. In comparison, when storing images that contain text, line art, or graphics – images with sharp transitions and large areas of solid color – the PNG format can compress image data more than JPEG can. Additionally, PNG is lossless, while JPEG produces visual artifacts around high-contrast areas. (Such artifacts depend on the settings used in the JPG compression; they can be quite noticeable when a low-quality [high-compression] setting is used.) Where an image contains both sharp transitions and photographic parts, a choice must be made between the two effects. JPEG does not support transparency.

JPEG's lossy compression also suffers from [[generation loss]], where repeatedly decoding and re-encoding an image to save it again causes a loss of information each time, degrading the image. Because PNG is lossless, it is suitable for storing images to be edited. While PNG is reasonably efficient when compressing photographic images, there are lossless compression formats designed specifically for photographic images, lossless [[WebP]] and [[Digital Negative|Adobe DNG]] (digital negative) for example. However these formats are either not widely supported, or are proprietary. An image can be stored losslessly and converted to JPEG format only for distribution, so that there is no generation loss.

While the PNG specification does not explicitly include a standard for embedding Exif image data from sources such as digital cameras, the preferred method for embedding EXIF data in a PNG is to use the non-critical ancillary chunk label <code>eXIf</code>.<ref name="PNG 1.2 eXIf">{{cite web|title=Extensions to the PNG 1.2 Specification, Version 1.5.0|url=http://ftp-osl.osuosl.org/pub/libpng/documents/pngext-1.5.0.html#C.eXIf|access-date=5 May 2020}}</ref>

Early web browsers did not support PNG images; JPEG and GIF were the main image formats. JPEG was commonly used when exporting images containing gradients for web pages, because of GIF's limited color depth. However, JPEG compression causes a gradient to blur slightly. A PNG format reproduces a gradient as accurately as possible for a given bit depth, while keeping the file size small. PNG became the optimal choice for small gradient images as web browser support for the format improved. No images at all are needed to display gradients in modern browsers, as gradients can be created using [[Cascading Style Sheets|CSS]].

=== JPEG-LS ===
[[JPEG-LS]] is an image format by the [[Joint Photographic Experts Group]], though far less widely known and supported than the other lossy JPEG format discussed above. It is directly comparable with PNG,{{Clarify|date=March 2010|reason=explain in which way it is directly comparable, or is this confused with Lossless JPEG?}} and has a standard set of test images.<ref name="jpegstdimg">{{cite web|url=http://www.itu.int/net/ITU-T/sigdb/speimage/T87.htm|title=T.87 : Lossless and near-lossless compression of continuous-tone still images – Baseline|publisher=International Telecommunication Union|access-date=20 March 2011}}</ref> On the Waterloo Repertoire ColorSet, a standard set of test images (unrelated to the JPEG-LS conformance test set), JPEG-LS generally performs better than PNG, by 10–15%, but on some images PNG performs substantially better, on the order of 50–75%.<ref name="pngcf">{{harvnb|Roelofs|2003|loc=[http://www.libpng.org/pub/png/book/chapter09.html Chapter 9. Compression and Filtering]}}</ref> Thus, if both of these formats are options and file size is an important criterion, they should both be considered, depending on the image.

=== TIFF ===
[[Tagged Image File Format]] (TIFF) is a format that incorporates an extremely wide range of options. While this makes TIFF useful as a generic format for interchange between professional image editing applications, it makes adding support for it to applications a much bigger task and so it has little support in applications not concerned with image manipulation (such as web browsers). The high level of extensibility also means that most applications provide only a subset of possible features, potentially creating user confusion and compatibility issues.

The most common general-purpose, lossless compression algorithm used with TIFF is Lempel–Ziv–Welch (LZW). This compression technique, also used in GIF, was covered by patents until 2003. TIFF also supports the compression algorithm PNG uses (i.e. Compression Tag 0008<sub>16</sub> '[[Adobe Systems|Adobe]]-style') with medium usage and support by applications. TIFF also offers special-purpose lossless compression algorithms like [[CCITT Group IV]], which can compress [[binary image|bilevel images]] (e.g., faxes or black-and-white text) better than PNG's compression algorithm.

PNG supports non-premultiplied alpha only<ref name="w3.org" /> whereas TIFF also supports "associated" (premultiplied) alpha.

== Software support ==
The official [[reference implementation]] of the PNG format is the [[library (computing)|programming library]] ''libpng''.<ref>{{cite web| url=http://www.libpng.org/pub/png/libpng.html| title=libpng| access-date=2013-07-13}}</ref> It is published as free software under the terms of a [[permissive free software license]]. Therefore, it is usually found as an important system library in free operating systems.

=== Bitmap graphics editor support for PNG ===
{{Main|Comparison of raster graphics editors}}

The PNG format is widely supported by graphics programs, including [[Adobe Photoshop]], [[Corel]]'s [[Corel Photo-Paint|Photo-Paint]] and [[Corel Paint Shop Pro|Paint Shop Pro]], the [[GIMP]], [[GraphicConverter]], [[Helicon Filter]], [[ImageMagick]], [[Inkscape]], [[IrfanView]], Pixel image editor, [[Paint.NET]] and [[Xara Photo & Graphic Designer]] and many others. Some programs bundled with popular [[operating system]]s which support PNG include [[Microsoft]]'s [[Microsoft Paint|Paint]] and [[Apple Inc.|Apple]]'s [[Apple Photos|Photos]]/[[iPhoto]] and [[Preview (macOS)|Preview]], with the GIMP also often being bundled with popular [[Linux]] distributions.

[[Adobe Fireworks]] (formerly by [[Macromedia]]) uses PNG as its native file format, allowing other image editors and preview utilities to view the flattened image. However, Fireworks by default also stores metadata for layers, animation, vector data, text and effects. Such files should not be distributed directly. Fireworks can instead export the image as an optimized PNG without the extra metadata for use on web pages, etc.{{Citation needed|date=May 2012}}

=== Web browser support for PNG ===
{{Main|Comparison of web browsers#Image format support|l1=Web browser image format support}}
PNG support first appeared in 1997, in [[Internet Explorer]] 4.0b1 (32-bit only for NT), and in [[Netscape]] 4.04.<ref>{{cite web| url = http://oregon.usgs.gov/png_images.html| title = Use of PNG Images to Display Data| publisher = Oregon Water Science Center| date = 16 February 2006| access-date = 11 September 2022| archive-date = 20 August 2008| archive-url = https://web.archive.org/web/20080820132117/http://oregon.usgs.gov/png_images.html| dead-url = yes}}</ref>

Despite calls by the [[Free Software Foundation]]<ref>{{cite web| url = https://www.gnu.org/philosophy/gif.html| title = Why There Are No GIF files on GNU Web Pages| work = [[GNU|GNU Operating System]]| date = 16 December 2008}}</ref> and the World Wide Web Consortium (W3C),<ref>{{cite web| url = http://www.w3.org/Press/PNG-fact.html| title = PNG Fact Sheet| publisher = World Wide Web Consortium| date = 7 October 1996}}</ref> tools such as gif2png,<ref>{{cite web|url=http://www.catb.org/~esr/gif2png/|title=Resource page for gif2png 2.5.11|work=catb.org}}</ref> and campaigns such as Burn All GIFs,<ref>{{cite web|url=http://burnallgifs.org/archives/|title=Burn All GIFs|website=burnallgifs.org}}</ref> PNG adoption on websites was fairly slow due to late and buggy support in Internet Explorer, particularly regarding transparency.<ref>{{cite magazine| url = https://www.pcmag.com/article2/0,2817,1645187,00.asp| title = PNG Transparency in Internet Explorer| magazine = [[PC Magazine]]| date = 5 October 2004}}</ref>

PNG compatible browsers include: Apple Safari, [[Google Chrome]], Mozilla Firefox, Opera, [[Camino (web browser)|Camino]], [[Internet Explorer 7]] (still numerous issues),<ref name="png-msie">{{cite web| url = http://www.libpng.org/pub/png/pngapbr.html#msie-win-unix| title = Browsers with PNG Support| date = 14 March 2009}}</ref> [[Internet Explorer 8]] (still some issues), [[Internet Explorer 9]] and many others. For the complete comparison, see Comparison of web browsers (Image format support).

Especially versions of Internet Explorer (Windows) below 9.0 (released 2011) have numerous problems which prevent it from correctly rendering PNG images.<ref name="png-msie"/>

* 4.0 crashes on large PNG chunks.<ref>{{cite web| url = http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_13501&sliceId=2| title = Windows Explorer Crashes When I Click on a Fireworks PNG File to View It| publisher = Adobe Systems| date = 5 June 2007}}</ref>
* 4.0 does not include the functionality to view .png files,<ref>{{cite web| url = http://support.microsoft.com/kb/174946| title = Unable to view .png images with Internet Explorer 4.0| work = Microsoft Knowledge Base}}</ref> but there is a registry fix.<ref name="png-msie" />
* 5.0 and 5.01 have broken OBJECT support.<ref>{{cite web| url = http://support.microsoft.com/kb/257081| title = PNGs That Are Inside of an Object Tag Print as a Negative Image| work = Microsoft Knowledge Base}}</ref>
* 5.01 prints palette images with black (or dark gray) backgrounds under Windows 98, sometimes with radically altered colors.<ref>{{cite web| url = http://support.microsoft.com/kb/255239| title = PNG Images Are Printed Improperly in Internet Explorer 5.01| work = Microsoft Knowledge Base}}</ref>
* 6.0 fails to display PNG images of 4097 or 4098 bytes in size.<ref>{{cite web| url = http://support.microsoft.com/kb/822071| title = You cannot view some PNG images in Internet Explorer 6| work = Microsoft Knowledge Base}}</ref>
* 6.0 cannot open a PNG file that contains one or more zero-length IDAT chunks. This issue was first fixed in security update 947864 (MS08-024). For more information, see this article in the Microsoft Knowledge Base: [http://support.microsoft.com/kb/947864/ 947864] MS08-024: Cumulative Security Update for Internet Explorer.<ref>{{cite web| url = http://support.microsoft.com/kb/897242| title = You cannot use Internet Explorer 6 to open a PNG file that contains one or more zero-length IDAT chunks| work = Microsoft Knowledge Base}}</ref>
* 6.0 sometimes completely loses ability to display PNGs, but there are various fixes.<ref name="libpng.org">{{cite web| url = http://www.libpng.org/pub/png/pngfaq.html#msie| title = PNG Frequently Asked Questions}}</ref>
* 6.0 and below have broken alpha-channel transparency support (will display the default background color instead).<ref>{{cite web| url = http://support.microsoft.com/kb/265221| title = PhD: Portable Network Graphics Lose Transparency in Web Browser| work = Microsoft Knowledge Base}}</ref><ref>{{cite web| url = http://support.microsoft.com/kb/294714| title = PNG Files Do Not Show Transparency in Internet Explorer| work = Microsoft Knowledge Base}}</ref><ref>{{cite web| url = http://www.alistapart.com/articles/pngopacity/| title = Cross-Browser Variable Opacity with PNG: A Real Solution| first = Michael| last = Lovitt| work = [[A List Apart]]| date = 21 December 2002| access-date = 21 July 2009| archive-url = https://web.archive.org/web/20110818032515/http://www.alistapart.com/articles/pngopacity/| archive-date = 18 August 2011| url-status = dead }}</ref> 
* 7.0 and below cannot combine 8-bit alpha transparency AND element opacity (CSS – filter: Alpha (opacity=xx)) without filling partially transparent sections with black.<ref>{{cite web| url = http://channel9.msdn.com/forums/TechOff/257324-IE7-alpha-transparent-PNG--opacity/| title = IE7 alpha transparent PNG + opacity| work = [[Channel 9 (discussion forum)|Channel 9]]| access-date = 23 January 2009| archive-url = https://web.archive.org/web/20110827114121/http://channel9.msdn.com/forums/TechOff/257324-IE7-alpha-transparent-PNG--opacity| archive-date = 27 August 2011| url-status = dead }}</ref>
* 8.0 and below have inconsistent/broken gamma support.<ref name="png-msie"/>
* 8.0 and below don't have color-correction support.<ref name="png-msie"/>

=== Operating system support for PNG icons ===
PNG icons have been supported in most distributions of Linux since at least 1999, in desktop environments such as [[GNOME]].<ref>{{cite web| url = http://developer.gnome.org/doc/whitepapers/libroadmap/| title = GNOME 1.0 Library Roadmap| first = Michael| last = Fulbright| year = 1999| access-date = 19 December 2007| archive-url = https://web.archive.org/web/20100130042852/http://developer.gnome.org/doc/whitepapers/libroadmap/| archive-date = 30 January 2010| url-status = dead }}</ref> In 2006, [[Microsoft Windows]] support for PNG icons was introduced in [[Windows Vista]].<ref>{{cite web|url=http://www.oone.googlepages.com/windows_vista_icons.htm|title=Windows Vista – Icons|access-date=2007-11-12|work=OOne|year=2007|archive-date=11 November 2007|archive-url=https://web.archive.org/web/20071111153449/http://www.oone.googlepages.com/windows_vista_icons.htm|url-status=dead}}</ref> PNG icons are supported in [[AmigaOS 4]], [[AROS]], [[macOS]], [[iOS]] and [[MorphOS]] as well. In addition, [[Android (operating system)|Android]] makes extensive use of PNGs.

== File size and optimization software ==
<!-- Deleted image removed: [[File:PNGOUT plugin.png|frame|right|Screenshots of the Save Options for the [[PNGOUT]] plugin which is included in the [[IrfanView]] image converter. The screenshots show the default settings.|{{Deletable image-caption|1=Sunday, 27 April 2008|date=May 2012}}]] -->
PNG file size can vary significantly depending on how it is encoded and compressed; this is discussed and a number of tips are given in ''PNG: The Definitive Guide.''<ref name="pngcf" />

=== Compared to GIF ===
Compared to GIF files, a PNG file with the same information (256 colors, no ancillary chunks/metadata), compressed by an effective compressor is normally smaller than a GIF image. Depending on the file and the compressor, PNG may range from somewhat smaller (10%) to significantly smaller (50%) to somewhat larger (5%), but is rarely significantly larger<ref name="pngcf" /> for large images. This is attributed to the performance of PNG's DEFLATE compared to GIF's [[LZW]], and because the added precompression layer of PNG's predictive filters take account of the 2-dimensional image structure to further compress files; as filtered data encodes differences between pixels, they will tend to cluster closer to 0, rather than being spread across all possible values, and thus be more easily compressed by DEFLATE. However, some versions of Adobe Photoshop, [[CorelDRAW]] and MS Paint provide poor PNG compression, creating the impression that GIF is more efficient.<ref name="pngcf" />

=== File size factors ===
PNG files vary in size due to a number of factors:
;color depth: Color depth can range from 1 to 64 bits per pixel.
;ancillary chunks: PNG supports metadata—this may be useful for editing, but unnecessary for viewing, as on websites.
;interlacing: As each pass of the Adam7 algorithm is separately filtered, this can increase file size.<ref name="pngcf" />
;filter: As a precompression stage, each line is filtered by a predictive filter, which can change from line to line. As the ultimate DEFLATE step operates on the whole image's filtered data, one cannot optimize this row-by-row; the choice of filter for each row is thus potentially very variable, though heuristics exist.<ref group="note">The filtering is used to increase the similarity to the data, hence increasing the compression ratio. However, there is theoretically no formula for similarity, nor absolute relationship between the similarity and compressor, thus unless the compression is done, one can't tell one filter set is better than another.</ref>
;compression: With additional computation, DEFLATE compressors can produce smaller files.
There is thus a filesize trade-off between high color depth, maximal metadata (including color space information, together with information that does not affect display), interlacing, and speed of compression, which all yield large files, with lower color depth, fewer or no ancillary chunks, no interlacing, and tuned but computationally intensive filtering and compression. For different purposes, different trade-offs are chosen: a maximal file may be best for archiving and editing, while a stripped down file may be best for use on a website, and similarly fast but poor compression is preferred when repeatedly editing and saving a file, while slow but high compression is preferred when a file is stable: when archiving or posting.
Interlacing is a trade-off: it dramatically speeds up early rendering of large files (improves latency), but may increase file size (decrease throughput) for little gain, particularly for small files.<ref name="pngcf" />

==== Lossy PNG compression ====
Although PNG is a lossless format, PNG encoders can preprocess image data in a lossy fashion to improve PNG compression. For example, quantizing a truecolor PNG to 256 colors allows the indexed color type to be used for a likely reduction in file size.<ref>{{cite web|url=http://pngmini.com/lossypng.html|title=PNG can be a lossy format|publisher=Pngmini.com|access-date=2014-02-01}}</ref>

=== Image editing software ===
Some programs are more efficient than others when saving PNG files, this relates to implementation of the PNG compression used by the program.

Many graphics programs (such as Apple's [[Preview (software)|Preview]] software) save PNGs with large amounts of metadata and color-correction data that are generally unnecessary for [[World Wide Web|Web]] viewing. Unoptimized PNG files from Adobe Fireworks are also notorious for this since they contain options to make the image editable in supported editors. Also CorelDRAW (at least version 11) sometimes produces PNGs which cannot be opened by Internet Explorer (versions 6–8).

Adobe Photoshop's performance on PNG files has improved in the CS Suite when using the Save For Web feature (which also allows explicit PNG/8 use).

Adobe's Fireworks saves larger PNG files than many programs by default. This stems from the mechanics of its ''Save'' format: the images produced by Fireworks' save function include large, private chunks, containing complete layer and vector information. This allows further lossless editing. When saved with the ''Export'' option, Fireworks' PNGs are competitive with those produced by other image editors, but are no longer editable as anything but flattened bitmaps. Fireworks is unable to save size-optimized vector-editable PNGs.

Other notable examples of poor PNG compressors include:
* Microsoft's Paint for Windows XP
* Microsoft Picture It! Photo Premium 9 <!-- explain? -->

Poor compression increases the PNG file size but does not affect the image quality or compatibility of the file with other programs.

When the color depth of a truecolor image is reduced to an 8-bit palette (as in GIF), the resulting image data is typically much smaller. Thus a truecolor PNG is typically larger than a color-reduced GIF, although PNG could store the color-reduced version as a palettized file of comparable size. Conversely, some tools, when saving images as PNGs, automatically save them as truecolor, even if the original data use only 8-bit color, thus bloating the file unnecessarily.<ref name="pngcf" /> Both factors can lead to the misconception that PNG files are larger than equivalent GIF files.

=== Optimizing tools ===
Various tools are available for optimizing PNG files; they do this by:
* (optionally) removing ancillary chunks,
* reducing color depth, either:
** use a palette (instead of RGB) if the image has 256 or fewer colors,
** use a smaller palette, if the image has 2, 4, or 16 colors, or
** (optionally) lossily discard some of the data in the original image,
* optimizing line-by-line filter choice, and
* optimizing DEFLATE compression.

==== Tool list ====
* [[pngcrush]] is the oldest of the popular PNG optimizers. It allows for multiple trials on filter selection and compression arguments, and finally chooses the smallest one. This working model is used in almost every png optimizer.
* advpng and the similar advdef utility in the AdvanceCOMP package recompress the PNG IDAT. Different DEFLATE implementations are applied depending on the selected compression level, trading between speed and file size: zlib at level 1, libdeflate at level 2, [[7-zip]]'s [[LZMA]] DEFLATE at level 3, and [[zopfli]] at level 4.
* [[pngout]] was made with the author's own deflater (same to the author's zip utility, kzip), while keeping all facilities of color reduction / filtering. However, pngout doesn't allow for using several trials on filters in a single run. It's suggested to use its commercial GUI version, pngoutwin, or used with a [[#Wrapper tools|wrapper]] to automate the trials or to recompress using its own deflater while keep the filter line by line.<ref name="pngoutreusefilter" group="note">Use pngout -f6 to reuse previous filter set</ref>
* zopflipng was also made with a self-own deflater, zopfli. It has all the optimizing features pngcrush has (including automating trials) while providing a very good, but slow deflater.

A simple comparison of their features is listed below.
{| class="wikitable"
|-
! Optimizer !! Chunk removal !! Color reduction !! Filtering !! Filter reuse<ref group="note">The tools offering such feature could act as a pure re-deflater to PNG files.</ref> !! Multiple trials on filters in a single run !! Deflater<ref group="note">zlib, the reference deflate implementation, compression is suboptimal even at the maximum level. See Zopfli, zip format in 7-zip and pngout.</ref>
|-
| advpng|| Yes|| No<ref group="note">Not only does advpng not support color reduction, it also fails on images with a reduced colorspace.</ref>|| 0|| No|| N/A<ref group="note">Advpng can only apply filter 0 globally, thus it's neither yes or no, but N/A.</ref>|| (multiple)
|-
| advdef|| No|| No|| Reuses previous filter set|| Always|| N/A|| (multiple)
|-
| pngcrush|| Yes|| Yes|| 0–4 or adaptive|| No|| Yes|| zlib
|-
| pngout|| Yes|| Yes|| 0–4 or adaptive|| Yes<ref name="pngoutreusefilter" group="note"/>|| No|| kzip
|-
| zopflipng|| Yes|| Yes|| 0–4 or adaptive with 2 different algorithms, or with a brute way|| Yes|| Yes|| zopfli
|}

Before zopflipng was available, a good way in practice to perform a png optimization is to use a combination of 2 tools in sequence for optimal compression: one which optimizes filters (and removes ancillary chunks), and one which optimizes DEFLATE. Although pngout offers both, only one type of filter can be specified in a single run, therefore it can be used with a [[#Wrapper tools|wrapper tool]] or in combination with pngcrush,<ref name="pngoutreusefilter" group="note"/> acting as a re-deflater, like advdef.

==== Ancillary chunk removal ====
For removing ancillary chunks, most PNG optimization tools have the ability to remove all color correction data from PNG files (gamma, white balance, ICC color profile, standard RGB color profile). This often results in much smaller file sizes. For example, the following command line options achieve this with pngcrush:

<code>pngcrush -rem gAMA -rem cHRM -rem iCCP -rem sRGB ''InputFile.png'' ''OutputFile.png''</code>

==== Filter optimization ====
pngcrush, pngout, and zopflipng all offer options applying one of the filter types 0–4 globally (using the same filter type for all lines) or with a "pseudo filter" (numbered 5), which for each line chooses one of the filter types 0–4 using an adaptive algorithm. Zopflipng offers 3 different adaptive method, including a brute-force search that attempts to optimize the filtering.<ref group="note">[pngcrush|pngout] -f OR zopflipng --filters</ref>

pngout and zopflipng provide an option to preserve/reuse<ref name="pngoutreusefilter" group="note"/><ref group="note">zopflipng --filters=p</ref> the line-by-line filter set present in the input image.

pngcrush and zopflipng provide options to try different filter strategies in a single run and choose the best. The freeware command line version of pngout doesn't offer this, but the commercial version, pngoutwin, does.<ref group="note">Pngoutwin's setting dialog for optimization offers the user a selection of filter strategies.</ref>

==== DEFLATE optimization ====
Zopfli and the [[7zip#Software development kit|LZMA SDK]] provide DEFLATE implementations that can produce higher [[Data compression ratio|compression ratio]]s than the zlib reference implementation at the cost of performance. AdvanceCOMP's <code>advpng</code> and <code>advdef</code> can use either of these libraries to re-compress PNG files. Additionally, [[PNGOUT]] contains its own [[proprietary software|proprietary]] DEFLATE implementation.

<code>advpng</code> doesn't have an option to apply filters and always uses filter 0 globally (leaving the image data unfiltered); therefore it should not be used where the image benefits significantly from filtering. By contrast, <code>advdef</code> from the same package doesn't deal with PNG structure and acts only as a re-deflater, retaining any existing filter settings.

=== Icon optimization ===
Since [[icon (computing)|icons]] intended for Windows Vista and later versions may contain PNG subimages, the optimizations can be applied to them as well. At least one icon editor, Pixelformer, is able to perform a special optimization pass while saving [[ICO (file format)|ICO]] files, thereby reducing their sizes. [[FileOptimizer]] (mentioned above) can also handle ICO files.

[[Apple Icon Image format|Icons for macOS]] may also contain PNG subimages, yet there isn't such tool available.{{cn|date=November 2021}}

== See also ==
* Computer graphics, including:
** [[Comparison of browser engines (graphics support)]]
* [[Image editing]]
* [[Image file formats]]
* Related graphics file formats
** APNG Animated PNG
** JPEG Network Graphics (JNG)
** Multiple-image Network Graphics (MNG)
* Similar file formats
** [[X PixMap]] for portable icons
* [[Scalable Vector Graphics]]
* WebP

== Explanatory notes ==
{{Reflist|group=note}}

== References ==
{{Reflist|30em}}

== Further reading ==
* {{cite journal|last=Roelofs|first=Greg|date=April 1997|title=Linux Gazette: History of the Portable Network Graphics (PNG) Format|journal=Linux Journal|publisher=Specialized Systems Consultants, Inc.|volume=1997|issue=36es|issn=1075-3583|url=http://linuxgazette.net/issue13/png.html}}
* {{cite book|last=Roelofs|first=Greg|title=PNG: The Definitive Guide|url=https://archive.org/details/pngdefinitivegui00roel|edition=2nd|year=2003|publisher=O'Reilly Media|isbn=1-56592-542-4|url-access=registration}}
* {{cite web|ref={{harvid|W3C|2003}}|url=http://www.w3.org/TR/PNG/|title=Portable Network Graphics (PNG) Specification|publisher=W3C|date=10 November 2003|edition=Second}}

== External links ==
* [http://www.libpng.org/pub/png/ PNG Home Site]
* [http://www.libpng.org/pub/png/libpng.html libpng Home Page]
* [http://www.libpng.org/pub/png/slashpng-1999.html ''The Story of PNG'' by Greg Roelofs]
* [http://www.w3.org/Graphics/PNG/Inline-img.html Test inline PNG images]
* {{IETF RFC|2083|link=no}}
* [http://hsivonen.iki.fi/png-gamma/ More information about PNG color correction]
* [http://php.net/gd The GD-library to generate dynamic PNG-files with PHP]
* [http://schaik.com/png/adam7.html PNG Adam7 interlacing]
* [http://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/ Encoding Web Shells in PNG files] {{Webarchive|url=https://web.archive.org/web/20170223222454/https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/ |date=23 February 2017 }}: Encoding human readable data inside an IDAT block.

{{Graphics file formats}}
{{Compression formats}}
{{Authority control}}

[[Category:Portable Network Graphics| ]]
[[Category:Computer-related introductions in 1996]]
[[Category:Graphics standards]]
[[Category:Image compression]]
[[Category:ISO standards]]
[[Category:Open formats]]
[[Category:Raster graphics file formats]]
[[Category:World Wide Web Consortium standards]]