ZIP Archive Inspector
Peek inside a ZIP without extracting — list every entry, size and CRC.
Overview
The ZIP archive inspector peeks inside a .zip file and lists every entry — file path, compressed size, uncompressed size, CRC-32, compression method, and modification time — without writing a single byte to disk. The archive itself is left untouched.
Sysadmins triaging suspicious uploads, developers debugging release artefacts, and content managers checking ZIP-based formats like .docx, .epub, and .xlsx reach for this when a directory listing is enough and a full extraction is unnecessary. Long-tail searches that lead here include "list files inside ZIP online", "view ZIP archive contents", and "inspect zip without extracting".
How it works
A ZIP file (PKWARE's APPNOTE specification, also published as ISO/IEC 21320-1 for the subset used by Office Open XML) ends with a central directory that lists every member entry with its offset, sizes, CRC-32, compression method, and timestamp. The inspector seeks to the end of the file, locates the end-of-central-directory record, walks the central directory, and emits one row per entry.
Because the central directory is the source of truth (no scanning of local file headers required), inspection is nearly instantaneous regardless of archive size. Zip64 archives (those exceeding 4 GB or containing more than 65,535 entries) are detected via the Zip64 end-of-central-directory locator and parsed using the extended fields.
Examples
- List every entry inside a
.docxto see its OOXML internals (word/document.xml,_rels/, etc.). - Audit a deployment ZIP for unexpected files before unpacking on a production server.
- Verify an
.epub'smimetypemember is stored first and uncompressed, as the EPUB spec requires. - Spot oversized entries that bloat a backup ZIP.
FAQ
Does it extract files?
No. Only the central directory metadata is read. The compressed and uncompressed sizes, CRC-32, and timestamp are all available without decompressing any bytes.
What compression methods are reported?
The numeric method code from APPNOTE is mapped to a name: 0 = Store, 8 = Deflate, 12 = BZip2, 14 = LZMA, 95 = XZ, 93 = Zstandard, and so on. Method 0 entries are stored uncompressed; sizes therefore match.
Can it inspect password-protected ZIPs?
The central directory itself is rarely encrypted, so the listing usually works fine. Entry contents that are encrypted with a password remain unreadable until an extractor with the key is used.
Why does the modification time look wrong?
Standard ZIP timestamps use MS-DOS time (two-second resolution) in local time without timezone. For more accurate timestamps, the inspector also reads the Unix-time and NTFS-time extra fields when present.
Can it spot CRC mismatches?
The header CRC-32 is reported, but verifying it against the actual data requires reading and decompressing each entry, which is outside the read-only scope of this inspector.