How to Inspect ZIP Contents Before Unzipping

Double-clicking a ZIP feels harmless. You see a folder icon, files appear, and you go on with your day. But the moment you extract, you have already trusted whatever the archive decided to write to disk: filenames, folder paths, sizes, even files that try to land outside the folder you opened. The safer move is to read the archive first and extract second. This guide walks through how to inspect a ZIP's contents without unpacking it, what each piece of metadata tells you, and how to catch the two things that bite people most: path traversal and files that are far bigger than they look.

A ZIP already lists everything, before you extract

Here is the concrete part most people never learn: a ZIP file stores a central directory near the end of the file. That directory is a table of every entry in the archive, and for each entry it records the name (full path), the compressed size, the uncompressed size, the compression method, the modification date, the CRC32 checksum, and an encryption flag. None of that requires decompressing a single byte. A ZIP reader can jump to the central directory, read the table, and hand you a complete manifest of the archive's contents in milliseconds.

That changes what "inspecting an archive" means. You do not need to extract to know what is inside. You can read the full file list, compare compressed against uncompressed sizes, check the dates, and look at the paths, all from the directory table. And because the paths and sizes are right there, you can spot suspicious entries, such as a name beginning with ../ (the classic zip-slip path traversal pattern) or an unexpected .exe in what was supposed to be a folder of PDFs, before you ever unpack it.

The ZIP Manifest Inspector does exactly this. It opens the file in your browser, reads the central directory, and shows every entry with its sizes, compression method, encryption flag, CRC32, and a column of risk notes.

What the metadata actually tells you

Each field in the directory answers a practical question:

• Entry name / path. This is the file's location once extracted. A clean entry looks like docs/readme.md. A dangerous one starts with ../, uses an absolute path like /etc/cron.d/job, or mixes \ separators to confuse a cross-platform extractor.
• Compressed vs uncompressed size. Divide one by the other and you get the expansion ratio. A text log might compress 20x, which is normal. A 2 KB entry that expands to 4 GB is the signature of a decompression bomb, and it deserves a hard stop.
• Modification date. Bundles built by a CI job tend to share one timestamp. A single file dated years apart from the rest is worth a second look, especially in a "fresh" release archive.
• CRC32. A per-entry checksum you can record for verification or compare against an expected value without extracting.
• Encryption flag. Tells you an entry is password-protected before you waste time trying to open it, and warns you that its contents cannot be scanned.

Reading those columns turns a blind double-click into a deliberate decision.

Worked example: catching a ../ path

Say a vendor sends me theme-pack.zip and asks me to drop it into a shared CMS. Before extracting, I open it in the inspector. The manifest lists what I expect: a handful of assets/css/*.css, some templates/*.html, an image folder. Sizes look sane, ratios are ordinary, dates all cluster around last Tuesday.

Then one row stops me:

name: ../../config/wp-config-override.php
compressed: 412 B
uncompressed: 1.2 KB
note: path traversal

That ../../ prefix means the entry is not trying to land inside the extraction folder. It is trying to climb two directories up and drop a PHP file next to a real config. A naive extractor that resolves paths literally would write it there, outside the folder I chose, which is the entire mechanism behind zip-slip. The manifest flagged it as path traversal and I never had to extract anything to see it. I reply to the vendor, ask them to rebuild the archive, and the override file never touches the server. Nothing was unpacked, so nothing was at risk.

That is the whole point: the dangerous file announced itself in the directory table. The only thing I had to do was read instead of trust.

Why local inspection matters here

Inspection happens entirely in your browser. The archive is parsed locally, and nothing about it is uploaded. That distinction matters more for archives than for most files, because a ZIP often carries private filenames, internal folder structures, customer data exports, or proprietary release contents. Sending an unknown archive to a remote service just to read its file list would mean leaking exactly the information you were trying to vet. Reading the central directory on your own machine means the only thing that ever leaves is your decision about whether to extract.

One caution: the CSV manifest you export can itself reveal private filenames and paths, so treat that export the same way you would treat the archive, and share it carefully.

A short checklist before you unzip

When an archive arrives from outside your team, run it past these questions first:

1. Do all the paths stay inside the folder? Reject anything with ../, a leading /, a drive letter, or backslash separators.
2. Are the uncompressed sizes plausible? Flag any entry whose expansion ratio or absolute size is absurd.
3. Are there file types you did not expect? A spreadsheet bundle should not contain executables or shell scripts.
4. Are there duplicate names? Two entries with the same path mean one silently overwrites the other on extraction.
5. Is anything encrypted that should not be? An unexpected password-protected entry hides its contents from any scan.

If everything passes, extract with confidence. If anything trips a flag, you caught it for the cost of reading a table instead of cleaning up after an extraction.

Pair it with the rest of your file checks

ZIP inspection fits naturally next to other local file checks. Once you have extracted (or before, if you have a loose download), confirm a file is what its extension claims with the file MIME type inspector, verify a download matches a published hash with the file checksum compare, and if you are renaming the extracted contents in bulk, plan the moves safely with the batch file rename planner. Each step keeps untrusted files honest before they reach the rest of your machine.

Inspecting a ZIP before you unzip costs a few seconds and removes a whole class of surprises. Read the manifest, check the paths and sizes, and let the central directory do the work it was already built to do.

---

Made by Toolora · Updated 2026-06-13