How to metadata extractor vs unzip -l / zipinfo / 7z l
- Step 1Decide if you only need names + sizes — If
unzip -lalready answers your question (just names, sizes, dates), you may not need either tool. The Metadata Extractor earns its place when you need host OS, version fields, GP flags, CRC, or a structured record to diff. - Step 2Compare the field coverage —
zipinfo -vis the CLI closest in coverage. The Metadata Extractor reports the same high-value fields (hostOS, versionMadeBy, GP flags, method, CRC) but omits the raw extra-field/comment bytes thatzipinfo -vdumps. For those bytes use /archive-tools/comment-extractor or /archive-tools/archive-signing-info. - Step 3Compare on format scope —
7z llists 7z/RAR/TAR/XZ and more. The Metadata Extractor is ZIP-only. For non-ZIP listings inside the JAD suite, /archive-tools/archive-previewer and /archive-tools/file-listing-generator read the broader format set via libarchive. - Step 4Run the browser tool — Drop your ZIP into /archive-tools/archive-metadata-extractor and click Process. The JSON appears instantly; copy or download it.
- Step 5Diff two reports — Save the JSON for an old and new build and diff them — because the schema is stable, the diff highlights exactly which entries changed method, size, timestamp, or flags. For a content-level archive diff, use /archive-tools/archive-diff.
- Step 6Verify integrity separately — The report gives you each entry's stored CRC-32, but it does not recompute CRCs against the payload. To actually validate, use /archive-tools/archive-integrity-tester (recomputes) or /archive-tools/checksum-generator (whole-file hash).
Field coverage: Metadata Extractor vs common CLIs
Which fields each tool surfaces for a ZIP. 'Yes' = reported directly; 'Partial' = derivable but not labelled; '—' = not shown.
| Field | Metadata Extractor (JAD) | unzip -l | zipinfo -v | 7z l |
|---|---|---|---|---|
| Entry name | Yes | Yes | Yes | Yes |
| Compressed / uncompressed size | Yes (both) | Uncompressed only | Yes (both) | Yes (both) |
| Last modified | Yes (ISO 8601) | Yes | Yes | Yes |
| Compression method name | Yes | — | Yes | Yes |
| CRC-32 | Yes (8-hex) | — | Yes | Yes |
| Host OS (versionMadeBy high byte) | Yes | — | Yes | — |
| Version made by / needed | Yes (both) | — | Yes | — |
| GP flags (encrypted / utf8 / dataDescriptor) | Yes | — | Yes | Partial |
| Comment / extra-field present | Yes (boolean) | — | Yes (full bytes) | — |
| Non-ZIP formats (7z/RAR/TAR) | — | — | — | Yes |
| Structured JSON output | Yes | — | — | — |
When to reach for which
Pick by the constraint that matters most for the task in front of you.
| Situation | Best choice | Why |
|---|---|---|
| Need a machine-readable record to diff or ingest | Metadata Extractor | Emits stable JSON; CLIs emit text you must parse |
| No shell access / locked-down machine | Metadata Extractor | Runs in any browser, nothing to install |
| File is 7z, RAR, or TAR | 7z l | Metadata Extractor is ZIP-only |
| Need the raw extra-field / comment bytes | zipinfo -v or /archive-tools/comment-extractor | Extractor reports presence, not contents |
| Quick eyeball of names and sizes | unzip -l | Fastest for the trivial case |
| Multi-GB archive in a scripted pipeline | CLI | No browser memory ceiling; archive tools have no public API |
Cookbook
The same ZIP, read three ways. Notice that the JAD JSON is the only output you can diff or jq without first parsing free text.
zipinfo -v vs the JSON report — same data, different shape
zipinfo -v prints host OS, version-made-by and the GP flags as labelled text. The Metadata Extractor reports the identical fields as JSON. The information overlaps; the format does not.
zipinfo -v run.zip (excerpt):
file system or operating system of origin: Unix
version of encoding software: 3.0
general purpose bit flag: 0x0800
file is encrypted: no
file name is encoded using UTF-8
Metadata Extractor JSON:
{
"name": "run.sh",
"versionMadeBy": 798,
"hostOS": 3,
"flags": { "encrypted": false, "utf8": true, "dataDescriptor": false }
}unzip -l shows less than you think
unzip -l omits the compressed size, the method, the CRC, and every header flag. If your question is 'what method/CRC/host-OS', unzip -l cannot answer it; the Metadata Extractor can.
unzip -l data.zip
Length Date Time Name
142998 05-04-2026 13:22 data.csv
Metadata Extractor for the same entry:
{
"name": "data.csv",
"compressedSize": 18234,
"uncompressedSize": 142998,
"compressionMethod": "Deflate",
"crc32": "7be2a91c",
"hostOS": 3
}7z l covers formats the Extractor cannot
Drop a .7z on the Metadata Extractor and it throws 'Not a valid ZIP archive…' because it parses the ZIP central directory only. 7z l reads it. Use auto-format-detector to route correctly.
$ 7z l archive.7z
Date Time Attr Size Compressed Name
2026-05-04 13:22:14 ....A 4096 1990 notes.txt
Metadata Extractor on archive.7z:
Error: Not a valid ZIP archive (or unsupported format for
metadata extraction).
→ For non-ZIP, use 7z l, or /archive-tools/archive-previewer.Diff two builds via stable JSON
Because the JSON schema never changes, saving a report per build lets you diff them directly. A method or timestamp change jumps out instantly — far cleaner than diffing zipinfo text.
$ diff <(jq -S . old-metadata.json) <(jq -S . new-metadata.json) < "lastModified": "2026-05-04T13:22:14.000Z", > "lastModified": "2026-05-11T09:01:02.000Z", < "crc32": "7be2a91c", > "crc32": "a0ffce21", → data.csv changed. For a content-level diff of two archives, use /archive-tools/archive-diff .
Privacy parity with a local CLI
A common reason teams pick a CLI is to avoid uploading sensitive archives. The Metadata Extractor preserves that: the file is read in-tab via the File API and never sent to a server, so it has the same privacy posture as running zipinfo locally — without needing the binary installed.
DevTools → Network while running the tool: (no request carrying archive bytes) Equivalent to: $ zipinfo -v sensitive.zip # also fully local Difference: the browser tool needs no install and no shell — useful on managed corporate machines.
Edge cases and what actually happens
You hand it a 7z, RAR, or tar.gz
Unsupported formatThe Metadata Extractor parses the ZIP central directory only; it does not use libarchive. A non-ZIP throws 'Not a valid ZIP archive (or unsupported format for metadata extraction).' This is where 7z l (or /archive-tools/archive-previewer inside the suite) wins. Confirm the format with /archive-tools/auto-format-detector.
You need the raw comment or extra-field bytes
By designzipinfo -v dumps the full comment and extra-field hex; the Metadata Extractor reports only hasComment/hasExtraField booleans. For the actual comment text use /archive-tools/comment-extractor; for signing extra fields use /archive-tools/archive-signing-info.
You want CRC verified, not just read
Read-onlyBoth this tool and the CLIs report the stored CRC-32 from the directory; reading it does not prove the payload matches. unzip -t recomputes and verifies. Inside the suite, /archive-tools/archive-integrity-tester recomputes CRCs against the data — use it when you need verification, not just the stored value.
Multi-GB archive in a CI job
Use the CLIArchive tools have no public REST API (apiAvailable: false) and the browser reads the whole file into an ArrayBuffer, so a multi-GB ZIP is better handled by a streaming CLI in CI. On Pro+ tiers the @jadapps/runner can drive the tool via headless browser, but for unattended pipelines a CLI is simpler.
zipinfo unavailable on Windows by default
Browser winszipinfo ships with Info-ZIP, not always present on a stock Windows box, and 7z needs a separate install. The Metadata Extractor needs only a browser — handy on a machine where you cannot install the Info-ZIP suite.
Tolerant CLI half-reads a damaged ZIP
DiffersSome CLIs try hard to list a damaged ZIP. The Metadata Extractor stops at the first central-directory record that lacks the 0x02014b50 signature, returning a partial report (or zero entries → error). If you need recovery rather than inspection, use /archive-tools/corrupted-zip-repair.
Field is derivable from CLI but not labelled
Partialunzip -l does not print the method or CRC at all; 7z l shows attributes but not the ZIP general-purpose flag bits the way zipinfo -v does. The Metadata Extractor labels encrypted, utf8, and dataDescriptor explicitly so you do not have to decode a hex flag word by hand.
ZIP64 archive with >65,535 entries
Limitation (both)The Metadata Extractor reads the 16-bit entry count from the EOCD, so it wraps past 65,535 entries (true ZIP64 directory locators are not followed). A ZIP64-aware CLI like 7z l reports the real count. For archives that large, prefer the CLI; tier entry caps (500 free / 50,000 pro) keep typical inputs in range anyway.
Frequently asked questions
Is the Metadata Extractor a drop-in replacement for zipinfo?
For the high-value fields, yes — it reports host OS, version-made-by/needed, the GP flag bits, method, CRC, sizes and timestamps, the same data zipinfo -v shows. It is not a full replacement because it omits the raw extra-field/comment byte dumps and is ZIP-only. Think of it as zipinfo in JSON for the fields most people actually act on.
Why doesn't it list my .7z or .rar?
It parses the ZIP central directory and nothing else — no libarchive bridge. Non-ZIP input throws 'Not a valid ZIP archive (or unsupported format for metadata extraction).' Use 7z l, or inside the suite /archive-tools/archive-previewer, for those formats.
Which is faster, the browser tool or a CLI?
For typical archives both are effectively instant — central-directory parsing is O(entries), not O(bytes). CLIs pull ahead only on multi-GB files where browser memory (the whole file is read into an ArrayBuffer) becomes the constraint.
Can I script the browser tool like a CLI?
Not via a public API — archive tools are browser-only (apiAvailable: false); Pro+ tiers can drive them through the @jadapps/runner headless-browser path. For true scripting, a Node ZIP library reading the central directory mirrors this tool's JSON schema closely.
Does it give me both compressed and uncompressed size?
Yes — compressedSize and uncompressedSize per entry, straight from the directory. unzip -l shows only the uncompressed length, so the Extractor is the quicker way to eyeball per-entry compression without zipinfo.
How do I verify a CRC rather than just read it?
This tool (and zipinfo/7z l) only report the stored CRC. To recompute and verify against the payload, use unzip -t on the CLI, or /archive-tools/archive-integrity-tester in the suite.
Is the output privacy-equivalent to a local CLI?
Yes. The file is read in-tab with the File API and never uploaded — the same local-only posture as running zipinfo on your machine, with the advantage that nothing needs installing.
Can I diff two archives' metadata?
Save the JSON for each and run diff (ideally after jq -S to sort keys). Because the schema is stable, changed method/size/timestamp/CRC fields stand out. For a content-level diff of two archives, use /archive-tools/archive-diff.
Does it show the same flags as zipinfo's hex flag word?
It decodes the three meaningful bits — bit 0 encrypted, bit 3 dataDescriptor, bit 11 utf8 — into named booleans. zipinfo -v prints the raw 0x flag word plus its own decode; the Extractor skips the raw word and gives you the booleans directly.
What about the host OS field — is it accurate?
It is taken straight from the high byte of versionMadeBy (versionMadeBy >> 8), the same source zipinfo uses. 0 = DOS/FAT, 3 = Unix, 11 = NTFS. It reflects what the creating tool wrote, which is occasionally misleading if that tool lied, but it is the canonical field.
When should I just use unzip -l?
When all you need is a quick list of names and uncompressed sizes and you already have a shell. The moment you need method, CRC, host OS, flags, or a structured record, switch to the Metadata Extractor or zipinfo -v.
Are the outputs interchangeable with other tools?
The report is plain JSON with no JAD-specific wrapper, so jq, scripts, and SIEM ingestion all read it directly. It describes a ZIP; it is not itself an archive.
Privacy first
Every JAD Archive tool runs entirely in your browser using fflate, @zip.js/zip.js, and the libarchive WASM bridge. Your archives never leave your device — verified by zero outbound network requests during processing.