How to file listing generator vs unzip -l, 7z l, and tar -tvf
- Step 1Decide on format coverage — All three CLIs are format-specialised (unzip = ZIP, tar = tar/gz, 7z = many). The File Listing Generator reads ZIP, 7z, RAR, TAR, GZ, BZ2 and XZ from one page — handy when you do not know the format up front.
- Step 2Compare ZIP metadata — For ZIPs the browser tool matches or beats unzip -l: it adds crc32, compression method names, and an isEncrypted flag in machine-readable columns, where unzip -l prints a fixed-width table you must parse.
- Step 3Compare the slow path — For 7z/RAR/BZ2/XZ the CLIs win on cost: 7z l reads the header without unpacking, while the browser tool extracts the archive in memory to list it. On a large 7z, prefer the CLI.
- Step 4Compare scripting — CLIs pipe into shell loops natively. The browser tool runs one archive per page load and has no public API yet, so for thousands of archives a CLI loop is the right call.
- Step 5Compare privacy — Both run locally — the browser tool never uploads, the CLI never leaves your box. The difference is install friction: the browser path needs only a tab.
- Step 6Pick per job — One-off, mixed-format, or no-install situations: use the browser tool. Bulk, very large 7z/RAR, or scripted pipelines: use the CLI.
File Listing Generator vs the common CLIs
All run locally and privately. The difference is install friction, format coverage, output shape, and the cost of listing non-ZIP formats.
| Capability | File Listing Generator | unzip -l | 7z l | tar -tvf |
|---|---|---|---|---|
| Install required | None (browser tab) | Yes | Yes (p7zip) | Yes |
| Formats listed | ZIP, 7z, RAR, TAR, GZ, BZ2, XZ | ZIP only | 7z, ZIP, RAR, many | tar, tar.gz, etc. |
| Output shape | CSV / JSON / TXT files | Fixed-width terminal table | Fixed-width terminal table | Fixed-width terminal table |
| crc32 / method / encryption flag | Yes, for ZIP (columns) | Partial (with -v) | Yes | No |
| Lists 7z/RAR without unpacking | No — extracts in memory | n/a | Yes (reads header) | n/a |
| Scriptable / batched | One archive per run, no API yet | Yes | Yes | Yes |
What the listFormat control gives you that CLIs do not by default
The browser tool's three formats map cleanly onto downstream consumers without post-processing.
| listFormat | Direct consumer | CLI equivalent effort |
|---|---|---|
csv | Excel / Sheets / BI import | unzip -l | awk then fix date columns and quote names |
json | Scripts, SIEM/Splunk ingestion | Custom parser over fixed-width CLI output |
txt | Paste into a ticket or PR | Close to raw CLI output, but locale-stable dates |
Cookbook
Same archive, two paths. These show where the browser tool's structured output saves a parsing step and where the CLI is genuinely the better choice.
unzip -l output vs the CSV listing
unzip -l prints a fixed-width table you must realign to load into a spreadsheet. The File Listing Generator emits ready-to-import CSV with extra columns (ratio, crc32, method, isEncrypted).
$ unzip -l project.zip
Length Date Time Name
--------- ---------- ----- ----
4821 2026-01-04 09:12 src/index.ts
2110 2026-01-04 09:11 README.md
File Listing Generator (csv):
name,size,compressedSize,ratio,lastModified,isDirectory,compressionMethod,crc32,isEncrypted
src/index.ts,4821,1503,68.8%,2026-01-04T09:12:00.000Z,false,Deflate,1a2b3c4d,false
README.md,2110,961,54.5%,2026-01-04T09:11:58.000Z,false,Deflate,9f00aa12,false7z l reads the header; the browser tool unpacks
For 7z the CLI is cheaper because it reads the archive header without extraction. The browser tool extracts in memory to enumerate, so on big 7z files the CLI wins on speed and RAM.
$ 7z l backup.7z # reads header only, fast Date Time Size Name 2026-02-11 18:40 184320 bin/app File Listing Generator on backup.7z: -> extracts archive in memory, then lists -> compressedSize == size, ratio 0.0% (no per-entry compressed size for 7z)
Locale-stable dates without a flag
CLI date output depends on the system locale. The browser tool always emits ISO-8601, so listings are comparable across machines and easy to sort.
CLI (locale-dependent): 04/01/2026 09:12 vs 01/04/2026 09:12 File Listing Generator: 2026-01-04T09:12:00.000Z (always ISO-8601)
JSON for a script, no parser needed
Instead of writing a parser over fixed-width CLI output, request listFormat: json and load it directly.
# Browser tool -> project-listing.json
node -e "const l=require('./project-listing.json'); console.log(l.filter(e=>e.isEncrypted).map(e=>e.name))"
# vs piping unzip -l through awk/sed to reconstruct the same arrayWhen the CLI is the right answer
Thousands of archives in a loop, or a multi-GB 7z, belong on the CLI. The browser tool runs one archive per page load and has no API yet.
# CLI handles batch + huge 7z natively:
for f in *.7z; do 7z l "$f" > "${f%.7z}.txt"; done
# Browser tool: one archive per run; for batch extraction use
# /archive-tools/batch-extraction-manager insteadEdge cases and what actually happens
Listing a 7z is slower than 7z l
By design7z l reads the 7z header without unpacking. The browser tool has no in-browser 7z header reader, so it extracts the archive in memory to enumerate entries. On large 7z/RAR files the CLI is materially faster and lighter on RAM.
No per-entry compressed size for non-ZIP
Expectedunzip -v and 7z l show real compressed sizes; the browser tool only has them for ZIP. For 7z/RAR/TAR/GZ it reports compressedSize equal to size, so ratio is 0.0%. Use /archive-tools/compression-ratio-calculator if you need ratios.
No public API to script the browser tool
ManualCLIs slot into shell loops; the File Listing Generator runs one archive per page load with no programmatic endpoint. For automation, a CLI is currently the better fit, or batch-extract first then process.
File over the tier cap is rejected before listing
Rejected (tier limit)A CLI lists any size your disk holds. The browser tool enforces tier caps first: 50 MB / 500 entries free, up to 2 GB / 500,000 on paid tiers. Oversized inputs never start.
Mislabelled extension
Supportedunzip refuses a non-ZIP; the browser tool detects format from magic bytes, so a .zip that is really a 7z is listed as 7z. This is one area where the browser tool is more forgiving than a single-format CLI.
RAR support
Supportedunzip cannot read RAR at all; the browser tool can, via the libarchive WASM bridge (read-only). It enumerates entries but, as with 7z, reports no per-entry compressed size.
Directory entries differ between paths
Expectedunzip -l lists directory entries; the browser tool lists them only for ZIP. Non-ZIP listings from the browser tool contain files only, with isDirectory always false.
Per-entry timestamps for non-ZIP
Expectedtar -tvf and 7z l show real per-entry mtimes. The browser tool only does so for ZIP; for other formats every lastModified is the archive file's own date. For accurate non-ZIP dates, prefer the CLI.
Frequently asked questions
Is the output the same as unzip -l?
It is richer and structured. unzip -l prints a fixed-width terminal table; the File Listing Generator emits CSV/JSON/TXT with extra columns: ratio, crc32, compressionMethod, and isEncrypted.
Which is faster for a big 7z, the CLI or the browser tool?
The CLI. 7z l reads the header without unpacking. The browser tool extracts the 7z in memory to enumerate it, so on large 7z/RAR files the CLI is faster and uses less RAM.
Can the browser tool list RAR like unrar?
Yes, read-only via the libarchive WASM bridge. unzip cannot read RAR, so for RAR the browser tool covers a gap, though without per-entry compressed sizes.
Does the browser tool need an install?
No. It runs in a browser tab. unzip, 7z, and tar all need to be installed, which is the main friction on locked-down machines.
Can I script the browser tool like a CLI?
Not yet — it runs one archive per page load and has no public API. For scripted or bulk work a CLI loop is currently the right tool.
Are the dates comparable across machines?
Yes. The browser tool always emits ISO-8601 dates regardless of OS locale, unlike CLI output which is locale-dependent unless you force a format.
Does either upload my archive?
No. The browser tool reads the file locally and never uploads; CLIs never leave your machine. Both are private — the browser tool just needs no install.
Which gives accurate compression ratios for non-ZIP?
The CLI (unzip -v, 7z l). The browser tool only computes ratios for ZIP. For per-file ratios on any format inside the JAD suite, use /archive-tools/compression-ratio-calculator.
Can the browser tool handle a mislabelled file?
Yes — it detects format from magic bytes, so a wrongly-named archive is still listed. A single-format CLI like unzip would reject it.
What about huge archives the CLI handles fine?
The browser tool caps at 2 GB even on the top tiers and enforces an entry-count limit. Beyond that a CLI is the only option.
Does the browser tool list encrypted ZIPs?
Yes, without a password, because it only reads metadata — the isEncrypted column flags protected entries. To detect encryption first, use /archive-tools/encrypted-archive-detector.
Where do I go for batch listing of many archives?
Extract them with /archive-tools/batch-extraction-manager, or get a size/type rollup across many archives with /archive-tools/batch-compression-report. The File Listing Generator itself is single-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.