How to troubleshooting the file listing generator
- Step 1Check the size cap first — Free rejects archives over 50 MB before processing; Pro 500 MB; Pro-media and Developer 2 GB. If you see a tier-limit message immediately, this is why — upgrade or shrink the archive.
- Step 2Then check the entry cap — Entry count is capped separately: Free 500, Pro 50,000, top tiers 500,000. A small archive with thousands of tiny files can pass on size but fail on entries.
- Step 3If a ZIP lists 0 entries, suspect the central directory — The ZIP path parses the End-Of-Central-Directory record; if it is missing or truncated, you get an empty listing. Recover with /archive-tools/corrupted-zip-repair, then re-list.
- Step 4Confirm the real format — Format is detected from magic bytes. Run /archive-tools/auto-format-detector to confirm what the file actually is — a renamed or unrecognised file lists nothing useful.
- Step 5If columns look blank, check the format — Blank crc32/method/isEncrypted and a 0.0% ratio are expected for any non-ZIP format. That is the engine, not a fault — only ZIP exposes those fields.
- Step 6If dates look wrong, check the format — All-identical dates on a non-ZIP listing are the archive file's own date. Only ZIP carries per-entry timestamps; list a ZIP if you need real entry dates.
Symptom to cause to fix
Work top to bottom — earlier rows are the more common and the cheaper to check.
| Symptom | Likely cause | Fix |
|---|---|---|
| Rejected before processing | File over the tier's size cap (50 MB free) | Upgrade tier, or shrink/split the archive |
| Rejected, but file is small | Over the entry-count cap (500 free) | Upgrade tier, or split the archive into fewer entries |
| ZIP lists 0 entries | Corrupt or truncated central directory | Run /archive-tools/corrupted-zip-repair, then re-list |
| Any format lists 0 entries | Format not recognised (bad magic bytes) | Confirm with /archive-tools/auto-format-detector |
| crc32 / method blank, ratio 0.0% | Input is a non-ZIP format | Expected — only ZIP exposes these; this is not an error |
| All dates identical / look wrong | Non-ZIP: dates fall back to the file's own date | List a ZIP for real per-entry dates |
What each format can and cannot show
Use this to tell an expected limitation apart from an actual failure.
| Format | Lists entries | crc32 / method / encryption | Per-entry dates | Lists directories |
|---|---|---|---|---|
| ZIP | Yes (central directory) | Yes | Yes | Yes |
| TAR / GZ | Yes (fflate) | No | No (file's date) | No |
| 7z / RAR / BZ2 / XZ | Yes (libarchive WASM) | No | No (file's date) | No |
| Unknown / unrecognised | No (0 entries) | No | No | No |
Cookbook
Diagnostic recipes mapping a symptom to the exact check and the real expected behaviour.
0-entry ZIP: confirm it's corruption
An empty listing on a ZIP you know has files almost always means the central directory could not be parsed. The CSV will contain only its header.
Downloaded project-listing.csv: name,size,compressedSize,ratio,lastModified,isDirectory,compressionMethod,crc32,isEncrypted (no further rows) -> central directory unreadable. Fix: /archive-tools/corrupted-zip-repair -> re-run File Listing Generator
Blank columns on a 7z are expected
A 7z listing with empty crc32/method and 0.0% ratio is not a bug — those fields are ZIP-only. The names and sizes are still correct.
name,size,compressedSize,ratio,lastModified,isDirectory,compressionMethod,crc32,isEncrypted docs/manual.pdf,1048576,1048576,0.0%,2026-04-02T08:00:00.000Z,false,,,false # real size ^ ^ blank method/crc32, 0.0% ratio = non-ZIP, by design
Wrong-looking dates: it's the format
If every entry shares the same timestamp, the input is non-ZIP and dates fall back to the archive file's own mtime. Re-list the contents as a ZIP if you need real dates.
non-ZIP listing (all identical):
bin/a,...,2026-04-02T08:00:00.000Z,...
bin/b,...,2026-04-02T08:00:00.000Z,...
^ archive file's date, not per-entry
ZIP listing of the same files: each entry shows its own dateTier rejection: size vs entries
Read the rejection: a 60 MB ZIP fails on size on Free; a 3 MB ZIP with 900 files fails on entry count. They are separate caps.
60 MB archive on Free -> rejected: over 50 MB size cap 3 MB / 900 entries on Free -> rejected: over 500-entry cap Fix: upgrade (Pro = 500 MB / 50,000 entries) or split the archive
Renamed file: detect the real format
A .zip that is actually a 7z still lists (detection is by magic bytes). A truly unrecognised file lists nothing — confirm with the detector.
/archive-tools/auto-format-detector on mystery.zip -> reports: 7z File Listing Generator then lists it as 7z (reduced columns). If the detector reports 'unknown' -> File Listing returns 0 entries.
Edge cases and what actually happens
ZIP returns an empty listing
Empty (parse fail)The End-Of-Central-Directory record could not be found or parsed — usually truncation or corruption. The output has only its header row. Run /archive-tools/corrupted-zip-repair and re-list the repaired file.
Unrecognised file returns nothing useful
Rejected (invalid format)Format is read from magic bytes; if detection returns unknown, the tool falls back to trying ZIP and an unrecognised file lists 0 entries. Confirm the true type with /archive-tools/auto-format-detector.
File over the size cap
Rejected (tier limit)Free stops at 50 MB, Pro 500 MB, Pro-media and Developer 2 GB. The check runs up front, so an oversized file never begins processing — there is nothing stuck, it was rejected.
File over the entry-count cap
Rejected (tier limit)A small archive with many entries can exceed the entry cap (Free 500, Pro 50,000, top tiers 500,000) even when within the size limit. The two caps are independent.
crc32, method, and encryption columns are blank
ExpectedThese are populated only for ZIP. For 7z/RAR/TAR/GZ/BZ2/XZ they are empty — this is the engine, not a failure. The name, size, and isDirectory (false) columns are still correct.
ratio reads 0.0% on a compressed file
ExpectedFor non-ZIP formats compressedSize equals size, so the ratio is 0.0% regardless of real compression. For genuine ratios use /archive-tools/compression-ratio-calculator.
Every entry has the same date
ExpectedOutside ZIP, each entry's lastModified is the archive file's own modified date, not its real mtime. Only ZIP listings show per-entry dates.
Directories missing from a non-ZIP listing
ExpectedThe non-ZIP extractor returns files only, so folder entries do not appear and isDirectory is always false. ZIP listings include directory entries.
Large 7z is slow or runs out of memory
By designNon-ZIP formats are extracted in memory to enumerate them, so a large 7z/RAR uses far more RAM than a same-sized ZIP. If it stalls, the archive may be too large for the browser to extract — convert to ZIP or list on a CLI.
Encrypted ZIP lists fine without a password
SupportedListing reads metadata only, so encrypted ZIPs list without a password and flag protected entries via isEncrypted: true. A password is only needed to extract, not to list.
Frequently asked questions
Why does my ZIP show 0 entries?
The central directory could not be parsed — usually a truncated or corrupt ZIP. The output has only its header. Repair with /archive-tools/corrupted-zip-repair, then re-list.
Why was my file rejected before it even started?
It exceeded a tier cap. Free is 50 MB / 500 entries; Pro 500 MB / 50,000; top tiers 2 GB / 500,000. Both size and entry count are checked before processing.
It rejected a small file — why?
You likely hit the entry-count cap, not the size cap. A 3 MB archive with 900 files exceeds the 500-entry free limit. Upgrade or split the archive.
Why is the crc32 column blank?
crc32 is only available for ZIP. For 7z/RAR/TAR/GZ it is empty by design — that is the engine, not a bug. Name and size are still accurate.
Why does the ratio say 0.0%?
Non-ZIP formats report compressedSize equal to size, so the ratio is always 0.0%. For real per-file ratios use /archive-tools/compression-ratio-calculator.
Why are all my entry dates the same?
For non-ZIP formats every entry's date falls back to the archive file's own modified date. Only ZIP listings carry real per-entry timestamps.
Why are directories missing from my listing?
The non-ZIP extractor returns files only, so folders are not listed and isDirectory is always false. ZIP listings do include directory entries.
It says unsupported format — what now?
The magic bytes did not match a known archive. Confirm the real type with /archive-tools/auto-format-detector; a renamed archive lists fine once detected, an unknown file lists nothing.
A big 7z stalls or runs out of memory — why?
Non-ZIP formats are extracted in memory to be listed, so a large 7z uses a lot of RAM. Convert it to ZIP first, or list it on a CLI where the header can be read without unpacking.
Does my archive get uploaded during troubleshooting?
No. The file is always read locally in your browser; nothing is uploaded. You can confirm this in DevTools, Network during a run.
Can I list an encrypted ZIP without the password?
Yes. Listing reads metadata only, so encrypted ZIPs list without a password and flag protected entries via isEncrypted. The password is only needed to extract.
The output is missing columns I expected — is it broken?
Almost certainly not. Reduced columns (blank crc32/method, 0.0% ratio) are the expected result for non-ZIP inputs. Check the detected format in the result panel against the format table above.
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.