How to troubleshooting the comment extractor
- Step 1Confirm it is actually a ZIP — The EOCD comment exists only in ZIP files. Run Auto Format Detector on the file — if it is really a 7z/rar/tar/gz (sometimes renamed
.zip), that explains the no-comment result. - Step 2Decide if 'no comment' is the truth — Most ZIPs have no global comment. If Auto Format Detector confirms a valid ZIP and you still get the no-comment notice, the archive simply was not stamped — that is the correct answer.
- Step 3Check the tier size limit — Free tier rejects files over 50 MB before reading. If you see a size-limit rejection, the archive is too big for your plan — Pro raises it to 500 MB, Pro-Media and Developer to 2 GB.
- Step 4Handle garbled text — If the comment shows replacement characters (�), it was written in a non-UTF-8 encoding (e.g. CP437). The tool decodes UTF-8 non-fatally; the raw bytes were preserved up to that limitation — re-stamp in UTF-8 if you control the build.
- Step 5Rule out a damaged tail — If you are sure a comment exists but the tool reports none, the EOCD region may be corrupt or overwritten. Run Corrupted ZIP Repair to assess and recover what is salvageable.
- Step 6Switch tools if needed — Need per-entry comments? Use Archive Metadata Extractor. Need to set/remove the comment? Use ZIP Comment Editor.
Symptom to cause to fix
Every observable result maps to one of these. The tool's pipeline (EOCD scan, length read, UTF-8 decode) is deterministic.
| Symptom | Likely cause | Fix |
|---|---|---|
(this archive has no global comment) on a real ZIP | ZIP simply has no EOCD comment (the common case) | Nothing to fix — that is the correct result |
(this archive has no global comment) on a 7z/rar/tar/gz | Not a ZIP — no EOCD record exists | Use Archive Metadata Extractor; this field is ZIP-only |
| Garbled / � characters | Comment written in non-UTF-8 encoding | Re-stamp as UTF-8 with ZIP Comment Editor if you control it |
| Size-limit rejection before processing | File over your tier cap (Free 50 MB) | Upgrade tier, or read with a local CLI for very large files |
| Sure a comment exists but none returned | Corrupt/overwritten EOCD tail | Run Corrupted ZIP Repair |
What the tool guarantees
Behaviours grounded in the implementation.
| Behaviour | Detail |
|---|---|
| Format read | ZIP EOCD global comment only |
| No-comment output | (this archive has no global comment) |
| Decoding | UTF-8, non-fatal (invalid bytes → U+FFFD) |
| Max comment | 65,535 bytes (16-bit EOCD length field) |
| Output | <archive>-comment.txt, MIME text/plain |
| Metrics | Comment length, Has comment |
Cookbook
Walk-throughs of the common symptoms and exactly how to resolve each.
No comment on a valid ZIP
The file is a genuine ZIP but was never stamped. The notice is correct — there is nothing to recover.
Auto Format Detector → 'ZIP archive (valid)' Comment Extractor → photos.zip Output: photos-comment.txt (this archive has no global comment) → correct: this ZIP has no EOCD comment
Renamed file: a 7z called .zip
Someone renamed a 7z to .zip. There is no EOCD, so no comment. Format detection reveals the truth.
Auto Format Detector → 'Detected: 7z (not ZIP)' Comment Extractor → archive.zip Output: archive-comment.txt (this archive has no global comment) → expected: 7z has no ZIP EOCD comment
Garbled comment from a legacy encoding
An old build tool wrote the comment in CP437. UTF-8 decode shows replacement characters for the non-ASCII bytes.
Output: legacy-comment.txt build 2019 �� release → comment was non-UTF-8; ASCII parts are readable. Re-stamp as UTF-8 via /archive-tools/zip-comment-editor
File too large for the free tier
A 1.2 GB archive is rejected before reading on the free tier. The comment is tiny, but the file must load into memory first.
Input: huge-dataset.zip (1.2 GB) on Free tier Result: rejected — exceeds 50 MB free-tier limit → upgrade to Pro (500 MB) / Pro-Media (2 GB), or read with `unzip -z` locally for very large files
Comment expected but tail is corrupt
You know the build stamped a comment, but the tool returns none. The EOCD may be damaged.
Output: build-comment.txt (this archive has no global comment) → but the build log shows a stamp was written. Run /archive-tools/corrupted-zip-repair to assess the EOCD region, then re-read the repaired file.
Edge cases and what actually happens
No comment on a valid ZIP
ExpectedMost ZIPs have no global comment. (this archive has no global comment) is the correct, expected output — the EOCD comment-length field is 0. Nothing is broken; the archive simply was not stamped.
Non-ZIP file (7z/rar/tar/gz)
ExpectedThe global comment is a ZIP EOCD feature. Non-ZIP formats have no EOCD, so the tool always reports no comment. Confirm with Auto Format Detector and switch to Archive Metadata Extractor for those formats.
Renamed file (7z disguised as .zip)
Detect firstA wrong extension is a frequent cause of confusion. Run Auto Format Detector to reveal the true format; if it is not ZIP, the no-comment result is correct.
Replacement characters in the output
Encoding mismatchInvalid-for-UTF-8 bytes are decoded to U+FFFD (the tool uses a non-fatal UTF-8 decoder). The original comment used a legacy encoding such as CP437. ASCII portions remain readable; re-stamp in UTF-8 with the ZIP Comment Editor to fix it permanently.
File over the tier size cap
RejectedFree tier rejects files over 50 MB before processing, because the archive is loaded into browser memory. The comment is tiny, but the whole file must fit. Upgrade (Pro 500 MB, Pro-Media/Developer 2 GB) or read very large files with a local CLI.
Comment exists but none returned
Possible corruptionIf you are certain a comment was written but the tool finds none, the EOCD region may be overwritten or the file truncated past it. The backward scan then fails to find the signature. Run Corrupted ZIP Repair to assess and recover.
Per-entry comment expected
Out of scopeThis tool reads only the single global comment. Each entry can have its own comment; those are not returned here. Use the Archive Metadata Extractor for per-entry comments.
Comment seems truncated
Spec limitIf the comment ends abruptly, the writer may have exceeded the 65,535-byte EOCD limit, which forces truncation at the spec maximum. Large provenance data belongs in a file inside the archive, not the comment.
Processing seems slow on a huge archive
Memory-boundThe whole file is loaded into browser memory before the EOCD is scanned, so a near-2 GB archive on a paid tier can be slow or memory-heavy on a low-RAM device. The comment read itself is instant; the load is the cost. Use a desktop with adequate RAM, or a local CLI, for very large files.
Frequently asked questions
Why does it always say 'no comment'?
Either the ZIP genuinely has no global comment (true for most archives) or the file is not a ZIP. Run Auto Format Detector to confirm the format; if it is a valid ZIP, the archive simply was not stamped, and the notice is correct.
My file is a 7z/rar/tar — why no comment?
The global comment is a ZIP End of Central Directory feature. 7z, rar, tar, and gz have no EOCD, so there is no comment to read. Use the Archive Metadata Extractor for those formats.
Why is the comment text garbled?
It was written in a non-UTF-8 encoding (commonly CP437 from older tools). The tool decodes as UTF-8 non-fatally, so invalid bytes become U+FFFD. ASCII parts stay readable; re-stamp as UTF-8 with the ZIP Comment Editor to fix it.
Why was my file rejected before it even processed?
It exceeds your tier's size limit. Free is 50 MB, Pro 500 MB, Pro-Media and Developer 2 GB. The comment is tiny, but the whole file must load into browser memory first. Upgrade or use a local CLI for very large archives.
I'm sure there's a comment — why doesn't it show?
The EOCD region may be corrupt, overwritten, or the file truncated past it, so the backward scan cannot find the signature. Run Corrupted ZIP Repair to assess and recover, then re-read.
Does it ever hang on 'Processing'?
Reading one EOCD record is near-instant, but the whole file is loaded into memory first. A near-2 GB archive on a low-RAM device can feel slow during the load. If it never finishes, hard-refresh (Ctrl+Shift+R) to clear a stale cached build and retry.
How do I know if the file is really a ZIP?
Run the Auto Format Detector — it reads the leading bytes and reports the true format, which catches renamed files (a 7z saved as .zip).
Can the tool read per-entry comments?
No. It reads only the single global comment. For per-entry (per-file) comments, use the Archive Metadata Extractor.
What's the maximum comment length?
65,535 bytes — the EOCD comment-length field is 16-bit. A comment that seems cut off may have been truncated at this spec maximum by the writer.
What output format does it produce?
A plain-text file, <archive>-comment.txt (MIME text/plain). It is the comment string, or the no-comment notice — never JSON or CSV.
How do I change or delete the comment?
Use the ZIP Comment Editor. It writes a new EOCD comment or clears it with an empty string. The Comment Extractor is read-only.
Is my file uploaded for any of this?
No. All reading happens in your browser tab; the file's bytes never reach a server. You can confirm this in DevTools, Network tab, while processing.
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.