View source for ZIP (file format)

{{short description|Family of archive file formats}}
{{Infobox file format
| name          = ZIP file format
| _noextcode    = yes
| extension    = {{code|.zip}}   {{code|.zipx}}   {{code|.z01}}   {{code|.zx01}}
| _nomimecode   = yes
| mime          = {{code|application/zip}}<ref name=iana>{{citation |url=https://www.iana.org/assignments/media-types/application/zip |title=Registration of a new MIME Content-Type/Subtype - application/zip |publisher=[[Organization:Internet Assigned Numbers Authority|IANA]] |date=20 July 1993 |access-date=5 January 2012}}</ref>
| uniform type  = com.pkware.zip-archive
| magic         = {{plainlist|
* ''none''
* {{code|PK\x03\x04}}
* {{code|PK\x05\x06}} (empty)
* {{code|PK\x07\x08}} (spanned)
}}
| developer     = PKWARE, Inc.
| released      = {{Start date and age|1989|02|14|df=y}}
| latest release version = 6.3.10
| latest release date = {{Start date and age|2022|11|01|df=y}}
| genre         = [[Data compression]]
| extended to   = {{Plainlist|
* [[JAR (file format)|JAR]], .ipa, [[Apk (file format)|.apk]] {{small|([[EAR (file format)|EAR]], RAR (Java), WAR)}}
* [[Office Open XML]] (Microsoft)
* [[Open Packaging Conventions]]
* [[OpenDocument]] (ODF)
* XPI (Mozilla extensions)
* [[DotLottie|dotLottie]]
}}
| standard      = [https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT APPNOTE] from PKWARE<br />
[http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=60101 ISO/IEC 21320-1:2015 (a subset of ZIP file format 6.3.3)]
| open          = Yes
}}


ZIP files generally use the file extensions {{mono|.zip}} or {{mono|.ZIP}} and the MIME media type {{code|application/zip}}.<ref name=iana/> ZIP is used as a base file format by many programs, usually under a different name. When navigating a file system via a user interface, graphical [[Icon (computing)|icons]] representing ZIP files often appear as a document or other object prominently featuring a [[Engineering:Zipper|zipper]].

== History ==
The {{mono|.ZIP}} file format was designed by Phil Katz of PKWARE and Gary Conway of Infinity Design Concepts. The format was created after Systems Enhancement Associates (SEA) filed a [[ARC (file format)#Lawsuits|lawsuit]] against PKWARE claiming that the latter's archiving products, named PKARC, were derivatives of SEA's [[ARC (file format)|ARC]] archiving system.<ref>{{cite news| url=https://www.wsj.com/articles/SB961363319756539141 |title=The Rise and Fall of a Software Star; Phil Katz Loved Code -- and Liquor |date=1997-08-15 |first1=Matt |last1 = Murray |first2 = Jeffrey A. |last2 = Tannenbaum |work={{wipe|The Wall Street Journal}} |edition=online |archive-url = https://web.archive.org/web/20160304211123/http://www.wsj.com/articles/SB961363319756539141 |archive-date = 2016-03-04 }} [http://www.bbsdocumentary.com/library/CONTROVERSY/LAWSUITS/SEA/pkzip.htm Alt URL]  Updated 2000-06-19.</ref>  The name "zip" (meaning "move at high speed") was suggested by Katz's friend, Robert Mahoney.<ref name=":0">{{Cite web|title=The BBS Documentary Library|url=http://www.bbsdocumentary.com/library/CONTROVERSY/LAWSUITS/SEA/|access-date=2020-09-25|website=www.bbsdocumentary.com}}</ref>  They wanted to imply that their product would be faster than [[ARC (file format)|ARC]] and other compression formats of the time.<ref name=":0" />  {{cns|date=May 2018|The earliest known version of ''.ZIP File Format Specification'' was first published as part of [[Software:PKZIP|PKZIP]] 0.9 package under the file APPNOTE.TXT in 1989.}}  By distributing the zip file format within APPNOTE.TXT, compatibility with the zip file format proliferated widely on the public Internet during the 1990s.<ref name="zipattack"/>

PKWARE and Infinity Design Concepts made a joint press release on February 14, 1989, releasing the {{mono|.ZIP}} file format into the [[Social:Public domain|public domain]].<ref>{{citation |url=http://brianlivingston.com/eweek/article2/0,4149,1257562,00.html |title=PKZip Must Open Up |author=Brian Livingston |quote=The ZIP file format is given freely into the public domain and can be claimed neither legally nor morally by any individual, entity or company |date=8 September 2003 |access-date=5 January 2012}}</ref><ref>{{citation |url=http://www.idcnet.us/ziphistory.html |title=Where Did Zip Files Come From Anyway? |publisher=Infinity Design Concepts, Inc. |access-date=2012-01-05}}</ref><ref>{{citation |url=http://cd.textfiles.com/pcmedic9310/MAIN/MISC/COMPRESS/ZIP.PRS |title=Press Release |year=1989 |access-date=5 January 2012}}</ref><ref>{{citation |url=http://www.pkware.com/about-us/phil-katz |title=Our Founder - Phil Katz |publisher=PKWARE |access-date=5 January 2012 | archive-url=https://web.archive.org/web/20101001181829/http://www.pkware.com/about-us/phil-katz | archive-date=2010-10-01 | url-status=dead}}</ref><ref>{{citation |url=http://mailman.vse.cz/pipermail/sc34wg1study/2010-November/000082.html |title=sc34-wg1 |author1=Gareth Horton |author2=Rob Weir |author3=Alex Brown |date=2 November 2010 |access-date=5 January 2012}}</ref>

=== Version history ===
The .ZIP File Format Specification has its own version number, which does not necessarily correspond to the version numbers for the PKZIP tool, especially with PKZIP 6 or later. At various times, PKWARE has added preliminary features that allow PKZIP products to extract archives using advanced features, but PKZIP products that create such archives are not made available until the next major release. Other companies or organizations support the PKWARE specifications at their own pace.

The .ZIP file format specification is formally named "APPNOTE - .ZIP File Format Specification" and it is published on the PKWARE.com website since the late 1990s.<ref>{{citation |url=http://www.pkware.com/support/zip-app-note/ |title= .ZIP Application Note |access-date=2012-07-20}}</ref> Several versions of the specification were not published. Specifications of some features such as BZIP2 compression, strong encryption specification and others were published by PKWARE a few years after their creation. The URL of the online specification was changed several times on the PKWARE website.

A summary of key advances in various versions of the PKWARE specification:
* 2.0: (1993)<ref name=iana/> File entries can be compressed with [[DEFLATE]] and use traditional PKWARE encryption (ZipCrypto).
* 2.1: (1996) Deflate64 compression
* 4.5: (2001)<ref name="zip45">{{citation |url=http://www.pkware.com/support/appnote.txt |archive-url=https://web.archive.org/web/20011203085830/http://www.pkware.com/support/appnote.txt |archive-date=3 December 2001 |title=File: APPNOTE.TXT - .ZIP File Format Specification Version: 4.5 Revised: 11/01/2001 |date=3 December 2001 |access-date=21 April 2012}}</ref> Documented 64-bit zip format.
* 4.6: (2001) BZIP2 compression (not published online until the publication of APPNOTE 5.2)
* 5.0: (2002) SES: [[Engineering:Data Encryption Standard|DES]], Triple DES, RC2, [[RC4]] supported for encryption (not published online until the publication of APPNOTE 5.2)
* 5.2: (2003)<ref>{{citation |url=http://www.pkware.com/documents/APPNOTE/APPNOTE-5.2.0.txt |title=APPNOTE.TXT - .ZIP File Format Specification, Version: 5.2 - Notification of Change |date=16 July 2003 |access-date=5 January 2012}}</ref><ref>{{citation |url=http://pkware.com/products/enterprise/white_papers/appnote.html |archive-url=https://web.archive.org/web/20030702014023/http://pkware.com/products/enterprise/white_papers/appnote.html |archive-date=2 July 2003 |title=File: APPNOTE.TXT - .ZIP File Format Specification Version: 5.2 - Notification of Change – Revised: 06/02/2003 |date=2 July 2003 |access-date=21 April 2012}}</ref> AES encryption support for SES (defined in APPNOTE 5.1 that was not published online) and AES from WinZip ("AE-x"); corrected version of RC2-64 supported for SES encryption.
* 6.1: (2004)<ref>{{citation |url=http://www.pkware.com/company/standards/appnote/ |archive-url=https://web.archive.org/web/20040819182806/http://www.pkware.com/company/standards/appnote/ |archive-date=19 August 2004 |title=File: APPNOTE - .ZIP File Format Specification Version: 6.1.0 - Notification of Change – Revised: 01/20/2004 |date=19 August 2004 |access-date=21 April 2012}}</ref> Documented certificate storage.
* 6.2.0: (2004)<ref name="zip620">{{citation |url=http://www.pkware.com/documents/APPNOTE/APPNOTE-6.2.0.txt |title=APPNOTE.TXT - .ZIP File Format Specification, Version: 6.2.0 - Notification of Change |date=26 April 2004 |access-date=5 January 2012}}</ref> Documented Central Directory Encryption.
* 6.3.0: (2006)<ref name="zip630">{{citation |url=http://www.pkware.com/documents/APPNOTE/APPNOTE-6.3.0.TXT |title=APPNOTE.TXT - .ZIP File Format Specification, Version: 6.3.0 |date=29 September 2006 |access-date=5 January 2012}}</ref> Documented Unicode ([[UTF-8]]) filename storage. Expanded list of supported compression algorithms (LZMA, PPMd+), encryption algorithms (Blowfish, Twofish), and hashes.
* 6.3.1: (2007)<ref name="zip631">{{citation |url=http://www.pkware.com/documents/APPNOTE/APPNOTE-6.3.1.TXT |title=APPNOTE.TXT - .ZIP File Format Specification, Version: 6.3.1 |date=11 April 2007     |access-date=25 June 2018}}</ref> Corrected standard hash values for SHA-256/384/512.
* 6.3.2: (2007)<ref name="zip632">{{citation |url=http://www.pkware.com/documents/APPNOTE/APPNOTE-6.3.2.TXT |title=APPNOTE.TXT - .ZIP File Format Specification Version: 6.3.2  |date=28 September 2007 |access-date=25 June 2018}}</ref> Documented compression method 97 ([[Software:WavPack|WavPack]]).
* 6.3.3: (2012)<ref name="zip633">{{citation |url=http://www.pkware.com/documents/APPNOTE/APPNOTE-6.3.3.TXT |title=APPNOTE.TXT - .ZIP File Format Specification Version: 6.3.3  |date=1 September 2012  |access-date=25 June 2018}}</ref> Document formatting changes to facilitate referencing the PKWARE Application Note from other standards using methods such as the JTC 1 Referencing Explanatory Report (RER) as directed by JTC 1/SC 34 N 1621.
* 6.3.4: (2014)<ref name="zip634">{{citation |url=http://www.pkware.com/documents/APPNOTE/APPNOTE-6.3.4.TXT |title=APPNOTE.TXT - .ZIP File Format Specification Version: 6.3.4  |date=1 October 2014    |access-date=25 June 2018 }}</ref> Updates the PKWARE, Inc. office address.
* 6.3.5: (2018)<ref name="zip635">{{citation |url=http://www.pkware.com/documents/APPNOTE/APPNOTE-6.3.5.TXT |title=APPNOTE.TXT - .ZIP File Format Specification Version: 6.3.5  |date=20 December 2018    |access-date=3 January 2019 }}</ref> Documented compression methods 16, 96 and 99, DOS timestamp epoch and precision, added extra fields for keys and decryption, as well as typos and clarifications.
* 6.3.6: (2019)<ref name="zip636">{{citation |url=http://www.pkware.com/documents/APPNOTE/APPNOTE-6.3.6.TXT |title=APPNOTE.TXT - .ZIP File Format Specification Version: 6.3.6  |date=26 April 2019    |access-date=3 January 2019 }}</ref> Corrected typographical error.
* 6.3.7: (2020)<ref name="zip637">{{citation |url=http://www.pkware.com/documents/APPNOTE/APPNOTE-6.3.7.TXT |title=APPNOTE.TXT - .ZIP File Format Specification Version: 6.3.7  |date=1 June 2020    |access-date=6 June 2020 }}</ref> Added [[Software:Zstandard|Zstandard]] compression method ID 20.
* 6.3.8: (2020)<ref name="zip638">{{citation |url=http://www.pkware.com/documents/APPNOTE/APPNOTE-6.3.8.TXT |title=APPNOTE.TXT - .ZIP File Format Specification Version: 6.3.8  |date=15 June 2020    |access-date=7 July 2020 }}</ref> Moved Zstandard compression method ID from 20 to 93, deprecating the former. Documented method IDs 94 and 95 ([[MP3]] and [[Software:XZ Utils|XZ]] respectively).
* 6.3.9: (2020)<ref name="zip639">{{citation |url=http://www.pkware.com/documents/APPNOTE/APPNOTE-6.3.9.TXT |title=APPNOTE.TXT - .ZIP File Format Specification Version: 6.3.9  |date=15 July 2020    |access-date=8 August 2020 }}</ref> Corrected a typo in Data Stream Alignment description.
* 6.3.10: (2022)<ref name="zip6310">{{citation |url=https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.10.TXT |title=APPNOTE.TXT - .ZIP File Format Specification Version: 6.3.10 |date=1 November 2022    |access-date=20 November 2022 }}</ref> Added several z/OS attribute values for APPENDIX B. Added several additional 3rd party Extra Field mappings.

[[Software:WinZip|WinZip]], starting with version 12.1, uses the extension {{mono|.zipx}} for ZIP files that use compression methods newer than DEFLATE; specifically, methods BZip, LZMA, PPMd, Jpeg and Wavpack. The last 2 are applied to appropriate file types when "Best method" compression is selected.<ref>{{cite web | url = http://www.winzip.com/comp_info.htm | title = Additional Compression Methods Specification | work = WinZip | publisher = [[Software:WinZip|WinZip]] Computing, S.L | location = Mansfield, CT | date = 19 May 2009 | access-date = 2009-05-24}}</ref><ref>{{cite web |url=http://kb.winzip.com/kb/entry/7/ |title=What is a Zipx File? |work=Winzip: Knowledgebase |publisher=[[Software:WinZip|WinZip]] Computing, S.L |location=Mansfield, CT |date=13 August 2010 |access-date=17 August 2010}}</ref>

=== Standardization ===
In April 2010, ISO/IEC JTC 1 initiated a ballot to determine whether a project should be initiated to create an ISO/IEC International Standard format compatible with ZIP.<ref>{{Cite web |url=http://kikaku.itscj.ipsj.or.jp/sc34/open/1414.pdf |title=ISO/IEC JTC 1/SC 34 — Document Description and Processing Languages |date=2010-04-12 |access-date=10 May 2014 |archive-url=https://web.archive.org/web/20140512221201/http://kikaku.itscj.ipsj.or.jp/sc34/open/1414.pdf |archive-date=12 May 2014 |url-status=dead |df=dmy-all }}</ref> The proposed project, entitled ''Document Packaging'', envisaged a ZIP-compatible 'minimal compressed archive format' suitable for use with a number of existing standards including [[OpenDocument]], [[Office Open XML]] and [[EPUB]].

In 2015, ISO/IEC 21320-1 "Document Container File — Part 1: Core" was published which states that "Document container files are conforming Zip files". It requires the following main restrictions of the ZIP file format:<ref>{{cite web |publisher=ITTF |title=ISO/IEC 21320-1:2015 Document Container File — Part 1: Core |url=http://www.iso.org/iso/catalogue_detail.htm?csnumber=60101 |date=2015}}</ref>
* Files in ZIP archives may only be stored uncompressed, or using the "deflate" compression (i.e. compression method may contain the value "0" - stored or "8" - deflated).
* The encryption features are prohibited.
* The digital signature features (from SES) are prohibited.
* The "patched data" features (from PKPatchMaker) are prohibited.
* Archives may not span multiple volumes or be segmented.

== Design ==
{{mono|.ZIP}} files are archives that store multiple files. ZIP allows contained files to be compressed using many different methods, as well as simply storing a file without compressing it. Each file is stored separately, allowing different files in the same archive to be compressed using different methods. Because the files in a ZIP archive are compressed individually, it is possible to extract them, or add new ones, without applying compression or decompression to the entire archive. This contrasts with the format of compressed tar files, for which such random-access processing is not easily possible.

A directory is placed at the end of a ZIP file. This identifies what files are in the ZIP and identifies where in the ZIP that file is located. This allows ZIP readers to load the list of files without reading the entire ZIP archive. ZIP archives can also include extra data that is not related to the ZIP archive. This allows for a ZIP archive to be made into a self-extracting archive (application that decompresses its contained data), by prepending the program code to a ZIP archive and marking the file as executable. Storing the catalog at the end also makes possible hiding a zipped file by appending it to an innocuous file, such as a GIF image file.

The {{mono|.ZIP}} format uses a [[Cyclic redundancy check#CRC-32 algorithm|32-bit CRC algorithm]] and includes two copies of each entry metadata to provide greater protection against data loss. The CRC-32 algorithm was contributed by David Schwaderer and can be found in his book "C Programmers Guide to NetBIOS" published by Howard W. Sams & Co. Inc.<ref>{{Cite web |last=eZine |date=2023-01-01 |title=The .ZIP File Format |url=https://www.neperos.com/article/rnsyi4f77b5c3ffb |website=Neperos.com |language=en-US}}</ref>

=== Structure ===
[[File:ZIP-64 Internal Layout.svg|thumb|400px|ZIP-64 Internal Layout]]

A ZIP file is correctly identified by the presence of an ''end of central directory record'' which is located at the end of the archive structure in order to allow the easy appending of new files. If the end of central directory record indicates a non-empty archive, the name of each file or directory within the archive should be specified in a ''central directory'' entry, along with other metadata about the entry, and an offset into the ZIP file, pointing to the actual entry data. This allows a file listing of the archive to be performed relatively quickly, as the entire archive does not have to be read to see the list of files. The entries within the ZIP file also include this information, for redundancy, in a ''local file header''. Because ZIP files may be appended to, only files specified in the central directory at the end of the file are valid. Scanning a ZIP file for local file headers is invalid (except in the case of corrupted archives), as the central directory may declare that some files have been deleted and other files have been updated.

For example, we may start with a ZIP file that contains files A, B and C. File B is then deleted and C updated. This may be achieved by just appending a new file C to the end of the original ZIP file and adding a new central directory that only lists file A and the new file C. When ZIP was first designed, transferring files by floppy disk was common, yet writing to disks was very time-consuming. If you had a large zip file, possibly spanning multiple disks, and only needed to update a few files, rather than reading and re-writing all the files, it would be substantially faster to just read the old central directory, append the new files then append an updated central directory.

The order of the file entries in the central directory need not coincide with the order of file entries in the archive.

Each entry stored in a ZIP archive is introduced by a ''local file header'' with information about the file such as the comment, file size and file name, followed by optional "extra" data fields, and then the possibly compressed, possibly encrypted file data. The "Extra" data fields are the key to the extensibility of the ZIP format. "Extra" fields are exploited to support the ZIP64 format, WinZip-compatible AES encryption, file attributes, and higher-resolution NTFS or Unix file timestamps. Other extensions are possible via the "Extra" field. ZIP tools are required by the specification to ignore Extra fields they do not recognize.

The ZIP format uses specific 4-byte "signatures" to denote the various structures in the file. Each file entry is marked by a specific signature. The end of central directory record is indicated with its specific signature, and each entry in the central directory starts with the 4-byte ''central file header signature''.

There is no BOF or EOF marker in the ZIP specification. Conventionally the first thing in a ZIP file is a ZIP entry, which can be identified easily by its ''local file header signature''. However, this is not necessarily the case, as this is not required by the ZIP specification - most notably, a self-extracting archive will begin with an executable file header.

Tools that correctly read ZIP archives must scan for the end of central directory record signature, and then, as appropriate, the other, indicated, central directory records. They must not scan for entries from the top of the ZIP file, because (as previously mentioned in this section) only the central directory specifies where a file chunk starts and that it has not been deleted. Scanning could lead to false positives, as the format does not forbid other data to be between chunks, nor file data streams from containing such signatures. However, tools that attempt to recover data from damaged ZIP  archives will most likely scan the archive for local file header signatures; this is made more difficult by the fact that the compressed size of a file chunk may be stored after the file chunk, making sequential processing difficult.

Most of the signatures end with the short integer 0x4b50, which is stored in little-endian ordering. Viewed as an [[ASCII]] string this reads "PK", the initials of the inventor Phil Katz. Thus, when a ZIP file is viewed in a text editor the first two bytes of the file are usually "PK". (DOS, OS/2 and Windows self-extracting ZIPs have an EXE before the ZIP so start with "MZ"; self-extracting ZIPs for other operating systems may similarly be preceded by executable code for extracting the archive's content on that platform.)

The {{mono|.ZIP}} specification also supports spreading archives across multiple file-system files. Originally intended for storage of large ZIP files across multiple [[Floppy disk|floppy disk]]s, this feature is now used for sending ZIP archives in parts over email, or over other transports or removable media.

The [[File Allocation Table|FAT filesystem]] of DOS has a timestamp resolution of only two seconds; ZIP file records mimic this. As a result, the built-in timestamp resolution of files in a ZIP archive is only two seconds, though extra fields can be used to store more precise timestamps. The ZIP format has no notion of [[Time zone|time zone]], so timestamps are only meaningful if it is known what time zone they were created in.

In September 2006, PKWARE released a revision of the ZIP specification providing for the storage of file names using [[UTF-8]], finally adding Unicode compatibility to ZIP.<ref name="zip630"/>

=== File headers ===
All multi-byte values in the header are stored in little-endian byte order. All length fields count the length in bytes.

==== Local file header ====

{|class="wikitable"
|+ Local file header
|-
! Offset !! Bytes !! Description<ref name="appnote">{{cite web|url=http://www.pkware.com/documents/casestudies/APPNOTE.TXT|format=TXT|title=File : APPNOTE.TXT - .ZIP File Format Specification : Version: 6.3.4|website=Pkware.com|access-date=2017-09-09}}</ref>
|-
|  0 || 4 || Local file header signature = 0x04034b50 (PK♥♦ or "PK\3\4")
|-
|  4 || 2 || Version needed to extract (minimum)
|-
|  6 || 2 || General purpose bit flag
|-
|  8 || 2 || Compression method; e.g. none = 0, DEFLATE = 8 (or "\0x08\0x00")
|-
| 10 || 2 || File last modification time
|-
| 12 || 2 || File last modification date
|-
| 14 || 4 || CRC-32 of uncompressed data
|-
| 18 || 4 || Compressed size (or 0xffffffff for ZIP64)
|-
| 22 || 4 || Uncompressed size (or 0xffffffff for ZIP64)
|-
| 26 || 2 || File name length (''n'')
|-
| 28 || 2 || Extra field length (''m'')
|-
| 30 || ''n'' || File name
|-
| 30+''n'' || ''m'' || Extra field
|}

The extra field contains a variety of optional data such as OS-specific attributes.  It is divided into records, each with at minimum a 16-bit signature and a 16-bit length. A ZIP64 local file extra field record, for example, has the signature 0x0001 and a length of 16 bytes (or more) so that two 64-bit values (the uncompressed and compressed sizes) may follow. Another common local file extension is 0x5455 (or "UT") which contains 32-bit UTC UNIX timestamps.

This is immediately followed by the compressed data.

==== Data descriptor ====

If the bit at offset 3 (0x08) of the general-purpose flags field is set, then the CRC-32 and file sizes are not known when the header is written. If the archive is in Zip64 format, the compressed and uncompressed size fields are 8 bytes long instead of 4 bytes long (see section 4.3.9.2<ref>{{cite web |title=File: APPNOTE.TXT - .ZIP File Format Specification |url=https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT |publisher=PKWARE Inc. |access-date=21 February 2022}}</ref>). The equivalent fields in the local header (or in the Zip64 extended information extra field in the case of archives in Zip64 format) are filled with zero, and the CRC-32 and size are appended in a 12-byte structure (optionally preceded by a 4-byte signature) immediately after the compressed data:

{|class="wikitable"
|+ Data descriptor
|-
! Offset !! Bytes !! Description<ref name="appnote"/>
|-
|  0 || 0 or 4 || ''Optional'' data descriptor signature = 0x08074b50
|-
|  0 or 4 || 4 || CRC-32 of uncompressed data
|-
|  4 or 8 || 4 or 8 || Compressed size
|-
|  8 or 12 or 20 || 4 or 8 || Uncompressed size
|}

==== Central directory file header ====

The central directory entry is an expanded form of the local header:
{|class="wikitable"
|+ Central directory file header
|-
! Offset !! Bytes !! Description<ref name="appnote"/>
|-
|  0 || 4 || Central directory file header signature = 0x02014b50
|-
|  4 || 2 || Version made by
|-
|  6 || 2 || Version needed to extract (minimum)
|-
|  8 || 2 || General purpose bit flag
|-
| 10 || 2 || Compression method
|-
| 12 || 2 || File last modification time
|-
| 14 || 2 || File last modification date
|-
| 16 || 4 || CRC-32 of uncompressed data
|-
| 20 || 4 || Compressed size (or 0xffffffff for ZIP64)
|-
| 24 || 4 || Uncompressed size (or 0xffffffff for ZIP64)
|-
| 28 || 2 || File name length (''n'')
|-
| 30 || 2 || Extra field length (''m'')
|-
| 32 || 2 || File comment length (''k'')
|-
| 34 || 2 || Disk number where file starts (or 0xffff for ZIP64)
|-
| 36 || 2 || Internal file attributes
|-
| 38 || 4 || External file attributes
|-
| 42 || 4 || Relative offset of local file header (or 0xffffffff for ZIP64).  This is the number of bytes between the start of the first disk on which the file occurs, and the start of the local file header. This allows software reading the central directory to locate the position of the file inside the ZIP file.
|-
| 46 || ''n'' || File name
|-
| 46+''n'' || ''m'' || Extra field
|-
| 46+''n''+''m'' || ''k'' || File comment
|}

==== End of central directory record (EOCD) ====
After all the central directory entries comes the end of central directory (EOCD) record, which marks the end of the ZIP file:

{|class="wikitable"
|+ End of central directory record (EOCD)
|-
! Offset !! Bytes !! Description<ref name="appnote"/>
|-
|  0 || 4 || End of central directory signature = 0x06054b50
|-
|  4 || 2 || Number of this disk (or 0xffff for ZIP64)
|-
|  6 || 2 || Disk where central directory starts (or 0xffff for ZIP64)
|-
|  8 || 2 || Number of central directory records on this disk (or 0xffff for ZIP64)
|-
| 10 || 2 || Total number of central directory records (or 0xffff for ZIP64)
|-
| 12 || 4 || Size of central directory (bytes) (or 0xffffffff for ZIP64)
|-
| 16 || 4 || Offset of start of central directory, relative to start of archive (or 0xffffffff for ZIP64)
|-
| 20 || 2 || Comment length (''n'')
|-
| 22 || ''n'' || Comment
|}

This ordering allows a ZIP file to be created in one pass, but the central directory is also placed at the end of the file in order to facilitate easy removal of files from multiple-part ''(e.g. "multiple floppy-disk")'' archives, as previously discussed.

=== Compression methods ===
The .ZIP File Format Specification documents the following compression methods: Store (no compression), Shrink (LZW), Reduce (levels 1–4; LZ77 + probabilistic), Implode, Deflate, Deflate64, [[Software:Bzip2|bzip2]], LZMA, [[Software:WavPack|WavPack]], PPMd, and a LZ77 variant provided by IBM z/OS CMPSC instruction.<ref>{{cite web|author=Adler, Mark|title=How are zlib, gzip and zip related? What do they have in common and how are they different?|url=https://stackoverflow.com/a/20765054/233286|access-date=2018-11-27}}</ref><ref name="zip635"/> The most commonly used compression method is [[DEFLATE]], which is described in IETF {{IETF RFC|1951}}.

Other methods mentioned, but not documented in detail in the specification include: PKWARE DCL Implode (old IBM TERSE), new [[Terse (file format)|IBM TERSE]], IBM LZ77 z Architecture (PFS), and a JPEG variant. A "Tokenize" method was reserved for a third party, but support was never added.<ref name="zip635"/>

The word ''Implode'' is overused by PKWARE: the DCL/TERSE Implode is distinct from the old PKZIP Implode, a predecessor to Deflate. The DCL Implode is undocumented partially due to its proprietary nature held by IBM, but [[Biography:Mark Adler|Mark Adler]] has nevertheless provided a decompressor called "blast" alongside zlib.<ref>{{cite web |title=Frequently Asked Questions about zlib |url=https://www.zlib.net/zlib_faq.html |website=zlib |quote=The PKWare DCL uses a completely different compressed data format than does PKZIP and zlib. However, you can look in zlib's  contrib/blast directory for a possible solution to your problem.}} ([https://github.com/madler/zlib/tree/master/contrib/blast contrib/blast])</ref>

=== Encryption ===
ZIP supports a simple [[Password|password]]-based [[Symmetric-key algorithm|symmetric encryption]] system generally known as ZipCrypto. It is documented in the ZIP specification, and known to be seriously flawed. In particular, it is vulnerable to [[Known-plaintext attack|known-plaintext attack]]s, which are in some cases made worse by poor implementations of random-number generators.<ref name="zipattack">{{cite web|author=Stay, Michael|url=http://math.ucr.edu/~mike/zipattacks.pdf|title=ZIP Attacks with Reduced Known Plaintext|website=Math.ucr.edu|access-date=2017-09-09|archive-url=https://web.archive.org/web/20171028074139/https://www.cs.auckland.ac.nz/~mike/zipattacks.pdf|archive-date=2017-10-28}}</ref> Computers running under native [[Software:Microsoft Windows|Microsoft Windows]] without third-party archivers can open, but not create, ZIP files encrypted with ZipCrypto, but cannot extract the contents of files using different encryption.<ref>{{Cite web |title=How To Password Protect A Zip File |author=Sandeep |website=Tech News Today |date=15 September 2021 |url= https://www.technewstoday.com/password-protect-a-zip-file/}}</ref>

New features including new [[Data compression|compression]] and [[Encryption|encryption]] (e.g. [[Advanced Encryption Standard|AES]]) methods have been documented in the ZIP File Format Specification since version 5.2. A [[Software:WinZip|WinZip]]-developed AES-based open standard ("AE-x" in APPNOTE) is used also by [[Software:7-Zip|7-Zip]] and Xceed, but some vendors use other formats.<ref>{{cite web|url=https://www.winzip.com/win/en/aes_info.html |title=AES Encryption Information: Encryption Specification AE-1 and AE-2|website=Winzip.com|access-date=2017-09-09}}</ref> PKWARE SecureZIP (SES, proprietary) also supports RC2, RC4, DES, Triple DES encryption methods, Digital Certificate-based encryption and authentication ([[X.509]]), and archive header encryption. It is, however, patented (see {{section link||Strong encryption controversy}}).<ref name="pkware">{{cite web|url=http://www.pkware.com/support/zip-app-note/|title=APPNOTE - PKZIP/SecureZIP - PKWARE Support Site|website=Pkware.com|access-date=9 September 2017}}</ref>

File name [[Encryption|encryption]] is introduced in .ZIP File Format Specification 6.2, which encrypts metadata stored in Central Directory portion of an archive, but Local Header sections remain unencrypted. A compliant archiver can falsify the Local Header data when using Central Directory Encryption. As of version 6.2 of the specification, the Compression Method and Compressed Size fields within Local Header are not yet masked.

=== ZIP64 ===
The original {{mono|.ZIP}} format had a 4&nbsp;GB (2<sup>32</sup> bytes) limit on various things (uncompressed size of a file, compressed size of a file, and total size of the archive), as well as a limit of 65,535 (2<sup>16</sup>-1) entries in a ZIP archive. In version 4.5 of the specification (which is not the same as v4.5 of any particular tool), PKWARE introduced the "ZIP64" format extensions to get around these limitations, increasing the limits to 16&nbsp;[[Exabyte|EB]] (2<sup>64</sup> bytes). In essence, it uses a "normal" central directory entry for a file, followed by an optional "zip64" directory entry, which has the larger fields.<ref>{{cite web|url=https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT|format=TXT|title=File : APPNOTE.TXT - .ZIP File Format Specification : Version: 6.3.4|website=Pkware.cachefly.net|access-date=2017-09-09}}</ref>

The format of the Local file header (LOC) and Central directory entry (CEN) are the same in ZIP and ZIP64. However, ZIP64 specifies an extra field that may be added to those records at the discretion of the compressor, whose purpose is to store values that do not fit in the classic LOC or CEN records. To signal that the actual values are stored in ZIP64 extra fields, they are set to 0xFFFF or 0xFFFFFFFF in the corresponding LOC or CEN record. If one entry does not fit into the classic LOC or CEN record, only that entry is required to be moved into a ZIP64 extra field. The other entries may stay in the classic record. Therefore, not all entries shown in the following table might be stored in a ZIP64 extra field. However, if they appear, their order must be as shown in the table.
{|class="wikitable"
|+ Zip64 extended information extra field
|-
! Offset !! Bytes !! Description<ref name="appnote"/>
|-
|  0 || 2 || Header ID 0x0001
|-
|  2 || 2 || Size of the extra field chunk (8, 16, 24 or 28)
|-
|  4 || 8 || Original uncompressed file size
|-
|  12 || 8 || Size of compressed data
|-
|  20 || 8 || Offset of local header record
|-
|  28 || 4 || Number of the disk on which this file starts
|}
On the other hand, the format of EOCD for ZIP64 is slightly different from the normal ZIP version.<ref name="appnote"/>
{|class="wikitable"
|+ Zip64 End of central directory record (EOCD64)
|-
! Offset !! Bytes !! Description<ref name="appnote"/>
|-
|  0 || 4 || End of central directory signature = 0x06064b50
|-
|  4 || 8 || Size of the EOCD64 minus 12
|-
| 12 || 2 || Version made by
|-
| 14 || 2 || Version needed to extract (minimum)
|-
| 16 || 4 || Number of this disk
|-
| 20 || 4 || Disk where central directory starts
|-
| 24 || 8 || Number of central directory records on this disk
|-
| 32 || 8 || Total number of central directory records
|-
| 40 || 8 || Size of central directory (bytes)
|-
| 48 || 8 || Offset of start of central directory, relative to start of archive
|-
| 56 || ''n'' || Comment (up to the size of EOCD64)
|}
It is also not necessarily the last record in the file. A End of Central Directory Locator follows (an additional 20 bytes at the end).

The File Explorer in Windows XP does not support ZIP64, but the Explorer in Windows Vista and later do.{{citation needed|date=October 2015}} Likewise, some extension libraries support ZIP64, such as DotNetZip, QuaZIP<ref>{{cite web | url=http://sourceforge.net/p/quazip/code/HEAD/tree/tags/0.6/quazip/NEWS.txt | title=QuaZIP changes | access-date=2014-01-25 | date=22 January 2014 }}</ref> and IO::Compress::Zip in Perl. [[Python (programming language)|Python]]'s built-in zipfile supports it since 2.5 and defaults to it since 3.4.<ref>{{cite web | url=http://bugs.python.org/issue17201 | title=Python enhancement: Use allowZip64=True by default (3.4) | access-date=2014-05-06}}</ref>  [[Software:OpenJDK|OpenJDK]]'s built-in java.util.zip supports ZIP64 from version Java 7.<ref>{{cite web | url=https://blogs.oracle.com/xuemingshen/entry/zip64_support_for_4g_zipfile | title=ZIP64, The Format for > 4G Zipfile, Is Now Supported | access-date=27 Sep 2010 | last=Shen | first =Xueming | date=17 April 2009 | work=Xueming Shen's Blog | publisher=[[Company:Sun Microsystems|Sun Microsystems]] }}</ref> [[Software:Android (operating system)|Android]] Java API support ZIP64 since Android 6.0.<ref>{{cite web|url=https://code.google.com/p/android/issues/detail?id=68666|title=Sign in - Google Accounts|website=code.google.com|access-date=9 September 2017}}</ref> Mac OS Sierra's Archive Utility notably does not support ZIP64, and can create corrupt archives when ZIP64 would be required.<ref>{{cite web|url=https://github.com/thejoshwolfe/yauzl/issues/69#issuecomment-359188643|title=Error: invalid central directory file header signature when unzipping big files, zipped by mac os · Issue #69 · thejoshwolfe/yauzl|website=GitHub}}</ref>  However, the ditto command shipped with Mac OS will unzip ZIP64 files.<ref>{{cite web | url=https://superuser.com/questions/114011/extract-large-zip-file-50-gb-on-mac-os-x | title=Extract large zip file (50 GB) on Mac OS X | access-date=17 Dec 2018  }}</ref> More recent{{when|date=March 2020}} versions of Mac OS ship with info-zip's zip and unzip command line tools which do support Zip64: to verify run zip -v and look for "ZIP64_SUPPORT".

=== Combination with other file formats ===
The {{mono|.ZIP}} file format allows for a comment containing up to 65,535 (2<sup>16</sup>−1) bytes of data to occur at the end of the file after the central directory.<ref name="appnote"/> Also, because the central directory specifies the offset of each file in the archive with respect to the start, it is possible for the first file entry to start at an offset other than zero, although some tools, for example [[Software:Gzip|gzip]], will not process archive files that do not start with a file entry at offset zero.

This allows arbitrary data to occur in the file both before and after the ZIP archive data, and for the archive to still be read by a ZIP application. A side-effect of this is that it is possible to author a file that is both a working ZIP archive and another format, provided that the other format tolerates arbitrary data at its end, beginning, or middle. Self-extracting archives (SFX), of the form supported by WinZip, take advantage of this, in that they are executable ({{mono|.exe}}) files that conform to the PKZIP AppNote.txt specification, and can be read by compliant zip tools or libraries.

This property of the {{mono|.ZIP}} format, and of the [[JAR (file format)|JAR]] format which is a variant of ZIP, can be exploited to hide rogue content (such as harmful Java classes) inside a seemingly harmless file, such as a GIF image uploaded to the web. This so-called [[Polyglot (computing)#GIFAR attack|GIFAR]] exploit has been demonstrated as an effective attack against web applications such as Facebook.<ref>{{cite web|url=http://www.infoworld.com/article/2653025/security/a-photo-that-can-steal-your-online-credentials.html|title=A photo that can steal your online credentials|first=Robert|last=McMillan|website=Infoworld.com|date=August 2008|access-date=9 September 2017}}</ref>

=== Limits ===
The minimum size of a {{mono|.ZIP}} file is 22 bytes. Such an ''empty zip file'' contains only an End of Central Directory Record (EOCD):
<br/>{{code|[0x50,0x4B,0x05,0x06,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00]}}

The maximum size for both the archive file and the individual files inside it is 4,294,967,295 bytes (2<sup>32</sup>−1 bytes, or 4&nbsp;GB minus 1 byte) for standard ZIP. For ZIP64, the maximum size is 18,446,744,073,709,551,615 bytes (2<sup>64</sup>−1 bytes, or 16&nbsp;EB minus 1 byte).<ref name="ziplimit">{{cite web|url=http://www.artpol-software.com/ZipArchive/KB/0610051629.aspx|title=ZipArchive: Zip64 Format: Crossing the Limits of File Sizes and Number of Files and Segments|website=Artpol-software.com|access-date=9 September 2017}}</ref>

=== Open extensions ===
==== Seek-optimized (SOZip) profile ====

A Seek-Optimized ZIP file (SOZip) profile<ref>{{cite web|last1=Rouault|first1=Even (OSGeo)|url=https://github.com/sozip/sozip-spec/blob/master/sozip_specification.md|format=markdown|title=Seek-optimized ZIP (SOZip) profile|website=github.com|access-date=2023-01-11}}</ref> has been proposed for the ZIP format. Such file contains one or several Deflate-compressed files that are organized and annotated such that a SOZip-aware reader can perform very fast random access (seek) within a compressed file. SOZip makes it possible to access large compressed files directly from a .zip file without prior decompression. It combines the use of ZLib block flushes issued at regular interval with a hidden index file mapping offsets of the uncompressed file to offsets in the compressed stream. ZIP readers that are not aware of that extension can read a SOZip-enabled file normally and ignore the extended features that support efficient seek capability.

=== Proprietary extensions ===
==== Extra field ====
{{mono|.ZIP}} file format includes an extra field facility within file headers, which can be used to store extra data not defined by existing ZIP specifications, and which allow compliant archivers that do not recognize the fields to safely skip them. Header IDs 0–31 are reserved for use by PKWARE. The remaining IDs can be used by third-party vendors for proprietary usage.

==== Strong encryption controversy ====
When [[Software:WinZip|WinZip]] 9.0 public beta was released in 2003, WinZip introduced its own AES-256 encryption, using a different file format, along with the documentation for the new specification.<ref>{{cite web|url=http://www.winzip.com/aes_info.htm|title=WinZip – AES Encryption Information|website=Winzip.com|access-date=2017-09-09}}</ref> The encryption standards themselves were not [[Proprietary software|proprietary]], but PKWARE had not updated APPNOTE.TXT to include Strong Encryption Specification (SES) since 2001, which had been used by PKZIP versions 5.0 and 6.0. WinZip technical consultant Kevin Kearney and [[Software:StuffIt|StuffIt]] product manager Mathew Covington accused PKWARE of withholding SES, but PKZIP chief technology officer Jim Peterson claimed that certificate-based encryption was still incomplete.

In another controversial move, PKWare applied for a patent on 16 July 2003 describing a method for combining ZIP and strong encryption to create a secure file.<ref>{{Cite web |url=http://www.infoworld.com/article/03/07/25/HNpkware_1.html |title=PKWare seeks patent for .zip file format |first=Robert |last=McMillan |date=July 25, 2003 |work=InfoWorld.com |access-date=16 June 2008 |archive-url=https://web.archive.org/web/20030810012219/http://www.infoworld.com/article/03/07/25/HNpkware_1.html |archive-date=2003-08-10 |url-status=dead |df=dmy-all }}</ref>

In the end, PKWARE and WinZip agreed to support each other's products. On 21 January 2004, PKWARE announced the support of WinZip-based AES compression format.<ref>{{cite web|url=http://www.news.com/2100-1012_3-5145491.html?tag=fd_nbs_ent|title=Software makers patch Zip tiff|website=News.com|access-date=9 September 2017}}</ref> In a later version of WinZip beta, it was able to support SES-based ZIP files.<ref>{{cite web|url=https://www.theregister.co.uk/2004/01/21/zip_file_encryption_compromise_thrashed/|title=Zip file encryption compromise thrashed out|author=John Leyden|website=Theregister.co.uk|access-date=9 September 2017}}</ref> PKWARE eventually released version 5.2 of the .ZIP File Format Specification to the public, which documented SES.  The Free Software project [[Software:7-Zip|7-Zip]] also supports AES, but not SES in ZIP files (as does its [[POSIX]] [[Porting|port]] p7zip).

When using AES encryption under WinZip, the compression method is always set to 99, with the actual compression method stored in an AES extra data field.<ref>{{cite web |url=http://www.winzip.com/win/en/aes_info.htm |title=AES Encryption Information: Encryption Specification AE-1 and AE-2 |website=Winzip.com |access-date=2017-09-09}}</ref> In contrast, Strong Encryption Specification stores the compression method in the basic file header segment of Local Header and Central Directory, unless Central Directory Encryption is used to mask/encrypt metadata.

== Implementation ==
There are numerous {{mono|.ZIP}} tools available, and numerous {{mono|.ZIP}} libraries for various programming environments; licenses used include [[Proprietary software|proprietary]] and [[Free software|free software]]. [[Software:WinZip|WinZip]], [[Software:WinRAR|WinRAR]], [[Software:Info-ZIP|Info-ZIP]], [[Software:ZipGenius|ZipGenius]], [[Software:7-Zip|7-Zip]], [[Software:PeaZip|PeaZip]] and [[Software:B1 Free Archiver|B1 Free Archiver]] are well-known {{mono|.ZIP}} tools, available on various platforms. Some of those tools have library or programmatic interfaces.

Some development libraries licensed under open source agreement are [[Software:Libzip|libzip]], [[Software:Libarchive|libarchive]], and [[Software:Info-ZIP|Info-ZIP]]. For Java: [[Java Platform, Standard Edition]] contains the package "java.util.zip" to handle standard {{mono|.ZIP}} files; the Zip64File library specifically supports large files (larger than 4&nbsp;GB) and treats {{mono|.ZIP}} files using random access; and the [[Software:Apache Ant|Apache Ant]] tool contains a more complete implementation released under the Apache Software License.

The [[Software:Info-ZIP|Info-ZIP]] implementations of the {{mono|.ZIP}} format adds support for Unix filesystem features, such as user and group IDs, file permissions, and support for symbolic links. The [[Software:Apache Ant|Apache Ant]] implementation is aware of these to the extent that it can create files with predefined Unix permissions. The Info-ZIP implementations also know how to use the error correction capabilities built into the {{mono|.ZIP}} compression format. Some programs do not, and will fail on a file that has errors.

The Info-ZIP Windows tools also support [[NTFS]] filesystem permissions, and will make an attempt to translate from NTFS permissions to Unix permissions or vice versa when extracting files. This can result in potentially unintended combinations, e.g. .exe files being created on NTFS volumes with executable permission denied.

Versions of Microsoft Windows have included support for {{mono|.ZIP}} compression in Explorer since the Microsoft Plus! pack was released for Windows 98. Microsoft calls this feature "Compressed Folders". Not all {{mono|.ZIP}} features are supported by the Windows Compressed Folders capability. For example, encryption is not supported in Windows 10 Home edition,<ref>{{cite web |last1=Maham Mukhtar |title=2 Ways To Fix "Encrypt Contents To Secure Data" Option Grayed Out In Windows 10 |url=https://www.itechtics.com/encrypt-contents-to-secure-data-option-grayed-out-fix/ |website=iTechtics |date=Aug 2017 |quote=EFS is available for all editions of Windows 10 except Windows 10 Home edition.}}</ref> although it can decrypt. Unicode entry encoding is not supported until [[Software:Windows 7|Windows 7]], while split and spanned archives are not readable or writable by the Compressed Folders feature, nor is AES Encryption supported.<ref>{{cite web|url=https://devblogs.microsoft.com/oldnewthing/20180515-00/?p=98755|title=Why is Windows Compressed Folders (Zip folders) support stuck at the turn of the century?|date=15 May 2018}}</ref>

[[OpenDocument]] Format (ODF) started using the zip archive format in 2005, ODF is an open format for office documents of all types, this is the default file format used in [[Software:Collabora Online|Collabora Online]], [[Software:LibreOffice|LibreOffice]] and others.<ref>{{Cite web |last=Hall |first=Jim |date=15 Aug 2022 |title=How ODT files are structured |url=https://opensource.com/article/22/8/odt-files |access-date=9 July 2023 |website=opensource.com}}</ref>  Microsoft Office started using the zip archive format in 2006 for their [[Office Open XML]] .docx, .xlsx, .pptx, etc. files, which became the default file format with [[Software:Microsoft Office 2007|Microsoft Office 2007]].

== Legacy ==
There are numerous other standards and formats using "zip" as part of their name. For example, zip is distinct from [[Software:Gzip|gzip]], and the latter is defined in [[IETF]] {{IETF RFC|1952}}. Both zip and gzip primarily use the [[DEFLATE]] algorithm for compression. Likewise, the ZLIB format (IETF {{IETF RFC|1950}}) also uses the DEFLATE compression algorithm, but specifies different headers for error and consistency checking. Other common, similarly named formats and programs with different native formats include [[Software:7-Zip|7-Zip]], [[Software:Bzip2|bzip2]], and [[Software:Rzip|rzip]].

== Concerns ==

The theoretical maximum compression factor for a raw DEFLATE stream is about 1032 to one,<ref>{{cite web | title=zlib Technical Details | url=https://www.zlib.net/zlib_tech.html | access-date=10 July 2019}}</ref> but by exploiting the ZIP format in unintended ways, ZIP archives with compression ratios of billions to one can be constructed. These [[Zip bomb|zip bomb]]s unzip to extremely large sizes, overwhelming the capacity of the computer they are decompressed on.<ref>{{cite news |last1=Smith |first1=Ernie |title=The Most Clever 'Zip Bomb' Ever Made Explodes a 46MB File to 4.5 Petabytes |url=https://www.vice.com/en_us/article/597vzx/the-most-clever-zip-bomb-ever-made-explodes-a-46mb-file-to-45-petabytes |access-date=10 July 2019 |work=Motherboard |agency=[[Company:Vice Media|Vice Media]] |date=10 July 2019}}</ref>

== See also ==
* [[Software:Comparison of file archivers|Comparison of file archivers]]
* [[Software:Comparison of archive formats|Comparison of archive formats]]
* [[List of archive formats]]

== References ==
{{Reflist}}

== External links ==
* [https://support.pkware.com/display/PKZIP/APPNOTE .ZIP Application Note] landing page for PKWARE's current and historical .ZIP file
* [https://www.iso.org/standard/60101.html ISO/IEC 21320-1:2015 — Document Container File — Part 1: Core]
* [https://www.hanshq.net/zip.html Zip Files: History, Explanation and Implementation]
* [https://www.hanshq.net/zip2.html Shrink, Reduce, and Implode: The Legacy Zip Compression Methods]
* [https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT APPNOTE.TXT] mirror
* [https://users.cs.jmu.edu/buchhofp/forensics/formats/pkzip-printable.html Structure of PKZip file] Format specifications, graphical tables


{{DEFAULTSORT:Zip (File Format)}}
[[Category:American inventions]]
[[Category:Archive formats]]

{{Sourceattribution|ZIP (file format)}}