Comments on this document can be sent to the PNG specification
Distribution of this memo is unlimited.
Initial proposals were in the png-list and png-mng-misc mailing lists, July 2000, July 2003, and January 2017.
At present, the latest version of this document is available on the
World Wide Web from
A copy of this version is archived at
Permission is granted to copy and distribute this document for any purpose and without charge, provided that the copyright notice and this notice are preserved, and that any substantive changes or deletions from the original are clearly marked.
This document describes a special-purpose chunk type that has been proposed for use in various PNG (Portable Network Graphics) and related multi-image applications. It has not yet been approved for registration by the PNG developers, and therefore is experimental and its format is subject to change. The proposed chunk is "eXIf" (an unregistered name that can be used in test implementations is "exIf").
Caution: the third letter in the chunk name is an uppercase "i", not a lowercase "L".
The words "must", "required", "should", "recommended", "may", and "optional" in this document are to be interpreted as described in RFC-2119 which is consistent with their plain English meanings. The word "can" carries the same force as "may".
It is proposed to add the following section to the document "Extensions to the PNG 1.2 Specification, Version 1.4.0"
101 88 73 102 (ASCII "eXIf")
The data segment of the eXIf chunk contains an Exif profile in the format specified in "4.7.2 Interoperability Structure of APP1 in Compressed Data" of [CIPA DC-008-2016] except that the JPEG APP1 marker, length, and the "Exif ID code" described in 4.7.2(C), i.e., "Exif", NULL, and padding byte, are not included.
The eXIf chunk may appear anywhere between the IHDR and IEND chunks except between IDAT chunks. The eXIf chunk size is constrained only by the maximum of 2^31-1 bytes imposed by the PNG specification. Only one eXIf chunk is allowed in a PNG datastream.
The eXIf chunk contains metadata concerning the original image data. If the image has been edited subsequent to creation of the Exif profile, this data might no longer apply to the PNG image data. It is recommended that unless a decoder has independent knowledge of the validity of the Exif data, the data should be considered to be of historical value only. It is beyond the scope of this specification to resolve potential conflicts between data in the eXIf chunk and in other PNG chunks.
73 73 42 0 (ASCII "II", 16-bit little-endian integer 42)or
77 77 0 42 (ASCII "MM", 16-bit big-endian integer 42)All other values are reserved for possible future definition.
The Exif specification does not contain a requirement that tag "value offset" pointers actually point to a valid address within the file (see Paragraph 4.6.2). Offsets are measured in bytes from the beginning of the TIFF header (the "II" or "MM"). Although this seems to be an implicit requirement, decoders should be prepared to encounter invalid pointers and deal with them appropriately.
We did explore other approaches involving saving only the safe-to-copy material and unsafe-to-copy material in different PNG chunks, or otherwise dissecting the Exif profile into multiple eXIf/eXIF chunks, but those do not meet our objective of providing a simple way of preserving the Exif profile existing in other image formats. See for example the Exif text keyword proposal of December 2000, at pmt.sourceforge.io/exif.