How to comment extractor vs unzip -z, zipnote, and 7z
- Step 1Pick the read tool by environment — On a machine where you already have
unzip,unzip -z archive.zipis the fastest one-liner. On a locked-down or shared machine with no install rights, open /archive-tools/comment-extractor in any browser. - Step 2Understand the format limit before you start — All of these read the ZIP EOCD comment. For
.7z/.rar, neitherunzip -znor JAD applies — use7zfor 7z headers, and remember JAD will report no comment for non-ZIP input. - Step 3Run the browser tool — Drop the
.ziponto the dropzone. The tool reads the EOCD comment and shows it withComment lengthandHas commentmetrics, then offers a<archive>-comment.txtdownload. - Step 4Compare the bytes — Diff JAD's
<archive>-comment.txtagainstunzip -z archive.zipoutput — they should match exactly, since both read the same EOCD comment field and decode the same bytes (JAD as UTF-8). - Step 5Choose the editor when you need to write — Neither reader edits the comment. Use
zipnoteon the CLI, or JAD's ZIP Comment Editor in the browser, to change or remove the comment. - Step 6Script the bulk case appropriately — For thousands of archives in a pipeline, the CLI (
for f in *.zip; do unzip -z "$f"; done) wins on automation. JAD's free tier reads one file at a time; paid tiers batch up to 20–100.
What each tool reads
All read the ZIP EOCD global comment. Behaviour for non-ZIP input and for per-entry comments differs.
| Tool | Reads global ZIP comment | Reads per-entry comments | Handles 7z/RAR | Edits comment |
|---|---|---|---|---|
| JAD Comment Extractor | Yes (EOCD scan, UTF-8 decode) | No | No — reports no comment | No (use ZIP Comment Editor) |
unzip -z | Yes | No | No | No |
zipnote | Yes | Yes (per-entry) | No | Yes |
zipinfo -v / unzip -v | Yes | Yes (verbose) | No | No |
7z l | Lists entries; comment surfacing varies | n/a | Yes (7z/rar listing) | No |
Practical trade-offs
Reading one EOCD record is fast everywhere; the differences are install, privacy, and automation.
| Factor | JAD Comment Extractor | CLI tools |
|---|---|---|
| Install required | None (browser) | Yes (unzip/zip/7z packages) |
| Admin rights | Not needed | Often needed to install |
| Privacy | Bytes stay in the tab, no upload | Local, but reads/writes on disk |
| Output | <archive>-comment.txt | stdout (redirect to file) |
| Batch / scripting | 1 file free, up to 20–100 on paid tiers | Trivial to loop over thousands |
| Cost | Free tier, no signup | Free, but per-machine setup |
Cookbook
How the browser tool lines up against the CLI for the same archive. Outputs should be byte-identical for valid ZIP comments.
Same comment, two tools
The browser tool and unzip -z read the same EOCD record. The text matches exactly.
$ unzip -z release.zip Archive: release.zip build=4821 commit=9f3c1ab built=2026-06-10 JAD output file: release-comment.txt build=4821 commit=9f3c1ab built=2026-06-10 → identical comment string
Non-ZIP input: both decline
Neither unzip -z nor JAD reads a 7z 'comment' — the EOCD record does not exist in 7z.
$ unzip -z backup.7z End-of-central-directory signature not found. JAD output file: backup-comment.txt (this archive has no global comment) → same conclusion: not a ZIP, no EOCD comment
Per-entry comments: CLI goes deeper
zipnote and zipinfo -v can show comments attached to individual entries. JAD's Comment Extractor reads only the single global comment — by design.
$ zipnote docs.zip @ readme.txt @ (comment above this line) reviewed-by: qa-team @ (zip file comment below this line) release candidate 3 JAD output file: docs-comment.txt release candidate 3 → JAD returns only the global comment; per-entry note needs /archive-tools/archive-metadata-extractor
Locked-down machine, no install
On a corporate laptop where you cannot install unzip, the browser tool is the only path that needs no admin rights.
$ unzip -z artifact.zip bash: unzip: command not found $ sudo apt install unzip [sudo] password: ← blocked, no admin rights → open https://.../archive-tools/comment-extractor drop artifact.zip → reads the comment, no install
Scripting many archives
When you have to read comments from thousands of archives, the CLI loop is the right tool. JAD's strength is the one-off, not the bulk pipeline.
# CLI: bulk read into a manifest for f in dist/*.zip; do echo "$f: $(unzip -z "$f" | tail -n +2)" done > comments.txt # JAD: free tier = 1 file; for many files use # /archive-tools/batch-compression-report
Edge cases and what actually happens
`unzip -z` reports 'signature not found' on a non-ZIP
ExpectedWhen the input is not a ZIP, unzip -z cannot find the EOCD and errors. JAD reaches the same conclusion more gently, returning (this archive has no global comment) instead of an error. Both are correct: there is no EOCD comment to read.
Output text differs between tools
Encoding differenceIf unzip -z shows mojibake but JAD shows clean text (or vice versa), the comment was written in a non-UTF-8 encoding. JAD always decodes as UTF-8 (non-fatal); a CLI may use the system locale. The underlying bytes are identical — only the decode differs.
Per-entry comment expected but missing
Out of scopeJAD reads only the global comment, so it never shows the per-entry comments that zipnote or zipinfo -v surface. This is a scope difference, not a bug. Use the Archive Metadata Extractor for per-entry data.
7z file with a 7z header comment
Not comparable7z stores metadata in its own header, not in a ZIP EOCD. 7z l may surface 7z-specific info, but JAD's Comment Extractor and unzip -z both correctly report no global comment, because the EOCD concept does not exist in 7z.
CLI not installed and no admin rights
Browser winsOn machines where unzip/7z cannot be installed, the CLI path is simply unavailable. The browser tool needs no install, no admin rights, and no PATH setup — drop the file and read.
Comment over 65,535 bytes expected
Spec limitNo ZIP tool can read a global comment longer than 65,535 bytes, because the EOCD length field is 16-bit. If you expected more, the data is stored elsewhere (e.g. a file inside the archive), not in the comment.
Archive larger than the tier cap
Rejected (browser)JAD's free tier rejects files over 50 MB before reading, since the file is loaded into browser memory. unzip -z has no such cap because it reads from disk. For very large archives without paid tiers, the CLI is the pragmatic choice.
Self-extracting EXE that wraps a ZIP
Often readableA self-extracting archive appends a stub before the ZIP payload. Both unzip -z and JAD scan for the EOCD near the end of the file, so the comment usually reads fine in either tool, provided trailing data does not exceed the scan window.
Frequently asked questions
Does JAD read the same comment as unzip -z?
Yes. Both read the ZIP EOCD global comment field. JAD decodes the bytes as UTF-8; for a UTF-8 comment the output is byte-identical to unzip -z.
Can JAD read 7z or RAR comments like 7z can?
No. The global comment is a ZIP EOCD feature. 7z and RAR use their own header formats, so JAD (and unzip -z) report no comment for them. Use 7z directly, or the Archive Metadata Extractor, for those formats.
Why use the browser tool instead of the CLI?
No install, no admin rights, no PATH setup, and the file's bytes never leave the tab. It is ideal on locked-down or shared machines, or for a quick one-off where setting up a CLI is more work than the task.
When is the CLI better?
Bulk pipelines (thousands of archives), CI/CD jobs, files larger than your tier cap, and any workflow where the archive already lives on a server you control. A for loop over unzip -z is hard to beat for volume.
Can JAD show per-entry comments like zipnote?
No. JAD's Comment Extractor reads only the single global comment. For per-entry comments, use zipnote/zipinfo -v on the CLI or JAD's Archive Metadata Extractor.
Can either tool edit the comment?
The readers (JAD Comment Extractor, unzip -z) only read. To edit, use zipnote on the CLI or JAD's ZIP Comment Editor in the browser.
Is the JAD output a real file I can pipe?
Yes — it is a plain .txt (<archive>-comment.txt, MIME text/plain), equivalent to redirecting unzip -z to a file. There is no JAD-specific wrapper around it.
What about file-size limits?
The CLI reads from disk with no size cap. JAD's free tier caps input at 50 MB (Pro 500 MB, Pro-Media/Developer 2 GB) because the archive is loaded into browser memory. The comment record itself is tiny either way.
Do the tools handle ZIP64?
Yes. ZIP64 archives still write a 32-bit EOCD record with the comment field for compatibility, which both JAD and unzip -z read.
Why does the CLI error but JAD just says 'no comment'?
On a non-ZIP file, unzip -z errors that it cannot find the EOCD signature. JAD reaches the same conclusion and returns (this archive has no global comment) rather than throwing — friendlier, same meaning.
Can I trust the browser tool with sensitive archives?
The file is read in your browser and not uploaded. That is the same trust boundary as running a local CLI: nothing transits a network. Verify in DevTools, Network tab, if you need proof.
Is there a JAD API to script this?
Not currently. For scripting today, the CLI (unzip -z) or a small Node script using a ZIP library is the way. JAD's value is the install-free, privacy-preserving one-off read.
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.