Editing PNG (section)

==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 eight-[[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 ([[hexadecimal|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>504E47</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 [[Multiple-image Network Graphics|MNG]], [[JPEG Network Graphics|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|publisher=No Starch Press}}</ref> [[Endianness|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|publisher=No Starch Press}}</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 standardized). 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 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.
* <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 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.{{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 two and six (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 correction|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>cICP</code> specifies the color space, transfer function and matrix coefficients as defined in ITU-T [[H.273]].<ref>{{Cite web |date=2023-09-21 |title=PNG Specification (Third Edition), cICP Coding-independent code points for video signal type identification |url=https://www.w3.org/TR/png/#cICP-chunk |website=w3.org}}</ref> It is intended for use with [[High-dynamic-range television|HDR imagery]] without requiring a color profile.<ref>{{Cite web |date=2023-05-03 |title=Adding support for HDR imagery to the PNG format |url=https://github.com/w3c/ColorWeb-CG/blob/08d0981ae5163b76275d0777d0166eab85396371/hdr-in-png-requirements.md |publisher=W3C Color on the Web Community Group}}</ref>
* <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 correction|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://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://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://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 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.
* <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 floatcenter"
|+ Allowed combinations of color type and bit depth<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 (computing)|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 color 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 three 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 floatcenter"
|+ 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" ("[[Alpha compositing|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 ===
PNG uses a two-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://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]])]]
The core PNG format does not support animation. [[Multiple-image Network Graphics|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>{{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.

With the development of the Third Edition of the PNG Specification, now maintained by the PNG working group,<ref>{{Cite web |date=2023-05-24 |title=PNG Third Edition, Explained |url=https://github.com/w3c/PNG-spec/blob/d5b059ad7f81e789b7689f1c0479db8d1cb41fb8/Third_Edition_Explainer.md#apng |website=W3C GitHub}}</ref> APNG will finally be incorporated into the specification as an extension.<ref>{{Cite web |date=2023-09-21 |title=PNG Specification (Third Edition), APNG: frame-based animation |url=https://www.w3.org/TR/png/#apng-frame-based-animation |website=w3.org}}</ref>

=== 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 RFC|1950}}
|-
|9
|0xD7
|ZLIB FCHECK value, no dictionary used, maximum compression algorithm<ref name="rfc1950" />
|-
|10
|0x63F8CFC00000
|A compressed DEFLATE block using the static Huffman code that decodes to 0x00 0xFF 0x00 0x00{{ref RFC|1951}}
|-
|16
|0x03010100
|The ZLIB check value: the [[Adler-32]] checksum of the uncompressed data<ref name="rfc1950" />
|-
|20
|0x18DD8DB0
|CRC of chunk's type and content (but not length)
|}
Displayed in the fashion of [[hex editor]]s, with on the left side byte values shown in [[Hexadecimal|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).