How can it read a ZIP without extracting everything?

A ZIP file ends with a central directory that indexes every entry: its name, compressed and uncompressed size, method, CRC, and date. The tool reads only that index, so listing is instant even for large archives.

Is my archive uploaded anywhere?

No. The .zip is read with FileReader and parsed in your browser. Even single-file extraction is done locally with the browser's built-in DecompressionStream. Nothing is transmitted.

Which entries can it extract?

Stored (uncompressed) and standard Deflate entries — by far the most common — extract directly using the browser's native Deflate support. Rare methods like BZIP2 or LZMA inside a ZIP cannot be expanded here.

What does the compression ratio mean?

It is how much smaller the stored data is than the original: 1 minus compressed size over uncompressed size, as a percentage. Already-compressed files like JPEGs or MP4s show near 0 percent; text and code compress well.

Why does a folder show as a zero-byte entry?

ZIP stores directories as separate entries whose names end in a slash and have zero length. They mark folder structure; the actual files are listed as their own full-path entries.

What is the ZIP File Inspector?

Free ZIP inspector. Drop a .zip file to list every entry with its uncompressed size, compressed size, compression ratio, method, CRC-32, and last-modified date — read from the central directory. Extract individual files locally. No upload; runs in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

ZIP File Inspector — Gera Tools

Name: ZIP File Inspector
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

A ZIP archive keeps an index of everything inside it called the central directory, written at the end of the file. That means you can see exactly what an archive contains — names, sizes, dates, compression — without unpacking a single byte. This inspector reads that directory in your browser and lets you pull out individual files on demand.

How it works

The tool first locates the End of Central Directory (EOCD) record by scanning backward for its signature 0x06054b50. The EOCD tells it how many entries exist and where the central directory starts.

It then walks each central directory file header (signature 0x02014b50), reading the compression method, CRC-32, compressed and uncompressed sizes, the MS-DOS packed date/time, and the file name. The packed date is decoded into a normal timestamp (DOS time stores the year as an offset from 1980).

To extract one file, the tool jumps to that entry’s local file header, skips its variable-length name and extra fields to find the data, then either copies stored bytes verbatim (method 0) or expands Deflate data with the browser’s DecompressionStream('deflate-raw') (method 8).

What you can learn from the listing

Compression ratios are the most immediately useful column. Files that compress well (source code, text, CSV, SVG) typically show 60–80% reduction. Files that are already compressed (JPEG, PNG, MP4, PDF with embedded images) show near 0% because Deflate can’t compress data that’s already been compressed — they’re stored verbatim. If you see a large bundle where many entries show 0% compression, the overall archive is effectively just concatenating pre-compressed files, which is common in production build zips.

Dates and times reveal when files were created or last modified according to the system that created the archive. These are MS-DOS timestamps rounded to 2-second precision and fixed at local time — they don’t carry timezone information, so files packed on a machine in a different timezone will have timestamps that appear offset.

CRC-32 is a 32-bit integrity check stored per file. If you extract a file and the bytes don’t produce the same CRC-32, the archive has been corrupted or truncated. The ZIP format stores the CRC in both the local file header (at the file’s location) and the central directory (at the end); inconsistencies between the two values indicate corruption.

Practical use cases

Auditing a deployment bundle — inspect which files are included, their sizes, and whether any unexpectedly large assets (videos, unminified JS) slipped in.
Recovering a single file — extract one document from a large archive without downloading and unpacking everything.
Verifying archive integrity — check that expected files are present and their sizes match what the packaging step should have produced.
Debugging build output — compare file counts and sizes across build runs to catch regressions in output size.

Limitations

ZIP64 archives (over 4 GB or more than 65,535 entries) use extended fields not covered by this reader; standard archives work fully.
Encrypted entries can be listed (names and sizes appear in the central directory) but cannot be extracted without the password.
Unusual compression methods such as BZIP2 (method 12) or LZMA (method 14) cannot be expanded by the browser’s native DecompressionStream; only method 0 (stored) and method 8 (Deflate) are supported for extraction.

Notes and tips

Listing is instant regardless of archive size because only the directory index is read.
The compression ratio column quickly shows which files actually compressed — useful for spotting already-compressed assets bloating an archive.
Extraction is local; the file you download never round-trips through a server.