How to edit, add, or remove a zip file's global comment online
- Step 1Drop your ZIP onto the tool — Select or drag a single ZIP-format file (
.zip,.jar,.apk,.docx,.xlsx,.epub, etc.). The tool reads the bytes locally — nothing is uploaded. There is one file input; this tool does not take a folder or batch of files. - Step 2Type the new comment, or leave it empty to remove — There is a single multi-line textarea labelled 'New comment (leave empty to remove)' with a placeholder of
Build 1.2.3 — built 2026-05-04. Whatever you type replaces the existing comment entirely — there is no append or prepend mode. An empty textarea removes the comment. - Step 3Keep the comment under 65,535 bytes — Standard ZIP caps the EOCD comment length at a 2-byte field (max 65,535 bytes). The tool slices your text to 65,535 characters before encoding to UTF-8, so plain-ASCII comments are safe up to that length. For multibyte text, keep it well under 65,535 characters so the encoded byte count also stays within the limit.
- Step 4Run the edit — The tool finds the EOCD signature
PK\x05\x06within the last 65,557 bytes of the file, copies everything up to and including the 22-byte EOCD header, patches the comment-length field, and appends your encoded comment. - Step 5Read the result metrics — The result panel reports
Comment length(the new comment's byte count) andRemoved?(true when the new length is 0). Use these to confirm a removal actually emptied the field. - Step 6Download the edited ZIP — The output downloads as
<name>-with-comment.zip. Extract it to confirm the file list is unchanged — only the trailing comment differs from the source.
What the single option does
The zip-comment-editor schema exposes exactly one control. There are no presets, no append/prepend toggle, and no 'read existing comment' field — to view an existing comment, use the comment-extractor sibling.
| Control (real UI) | Type | Default | Effect |
|---|---|---|---|
| New comment | Multi-line textarea (newComment) | Empty string | Text typed here replaces the entire EOCD comment, encoded as UTF-8 and sliced to 65,535 characters |
| (empty textarea) | — | — | Sets the comment-length field to 0 — the comment is removed; result metric Removed? becomes true |
| Placeholder shown | Hint only | Build 1.2.3 — built 2026-05-04 | Illustrative only; placeholder text is not written unless you type it |
Accepted vs rejected inputs
The tool searches the file's tail for the standard EOCD signature. Any container that is really a ZIP works; non-ZIP archive formats do not.
| Input | Works? | Why |
|---|---|---|
.zip | Yes | Native ZIP with an EOCD record |
.jar / .apk / .war | Yes | Java/Android packages are ZIP containers |
.docx / .xlsx / .pptx / .epub | Yes | Office Open XML and EPUB are ZIP under the hood — note editing the comment is safe but these formats may also embed their own metadata elsewhere |
.7z, .rar, .tar, .tar.gz, .gz | No | No EOCD record — the tool throws 'Not a valid ZIP archive'. Convert with archive-format-converter first if you need a ZIP |
| Corrupt ZIP missing its EOCD | No | If the PK\x05\x06 signature is gone, the comment cannot be located — try corrupted-zip-repair |
Tier limits for the archive family
Limits apply to the input ZIP. zip-comment-editor takes one file at a time, so the per-archive size and entry-count caps are what matter; batch-file caps do not apply.
| Tier | Max file size | Max entries per archive | Files at once |
|---|---|---|---|
| Free | 50 MB | 500 | 1 |
| Pro | 500 MB | 50,000 | 20 |
| Pro-media | 2 GB | 500,000 | 100 |
| Developer | 2 GB | 500,000 | unlimited |
Cookbook
Concrete before/after examples of the comment edit. The 'file list' never changes — only the trailing EOCD comment does.
Add a build stamp to a release ZIP
Stamp a distribution archive with a human-readable build marker. The comment is visible in most unzip tools' 'archive comment' field and via unzip -z on the command line, but does not affect extraction.
Input: release.zip (comment: empty) New comment: Build 1.2.3 — built 2026-05-04 Result metrics: Comment length: 29 Removed?: false Download: release-with-comment.zip Verify (CLI): unzip -z release-with-comment.zip → Build 1.2.3 — built 2026-05-04
Strip a leaked path from a comment
Some archivers write the source directory or username into the comment. To clear it for public distribution, leave the textarea empty.
Input: dist.zip comment: C:\Users\jdoe\secret-project\out — packed by jdoe New comment: (leave empty) Result metrics: Comment length: 0 Removed?: true Download: dist-with-comment.zip (comment now blank)
Confirm entry data is unchanged
Because the tool only rewrites the trailing comment, the central directory and all entries are untouched. A directory listing before and after is identical.
Before: unzip -l app.zip index.html app.js styles.css (3 files) After: unzip -l app-with-comment.zip index.html app.js styles.css (3 files) ← identical listing
Add a UTF-8 / emoji comment
Comments are UTF-8 encoded, so non-ASCII text and emoji are preserved. Keep multibyte text short so the encoded byte length stays under 65,535.
New comment: Versión 2.0 — ✓ verificado UTF-8 bytes written: 31 (more than the 28 characters, because á, ó, ✓ are multibyte) Result metrics: Comment length: 31 Removed?: false
Edit the comment on a .docx (ZIP container)
Office files are ZIP archives, so the editor can stamp them. The document opens normally afterward because Word ignores the EOCD comment.
Input: report.docx (a ZIP container) New comment: Final draft — approved 2026-06-10 Download: report-with-comment.zip Rename to report.docx → opens normally in Word; the archive comment is visible to ZIP tools only.
Edge cases and what actually happens
Input is a 7z, rar, or tar archive
RejectedThese formats have no End of Central Directory record. The tool throws 'Not a valid ZIP archive — no End of Central Directory record found.' Comments are a ZIP-specific feature; convert to ZIP with archive-format-converter first if you need this.
Comment longer than 65,535 characters
TruncatedThe ZIP comment-length field is 2 bytes (max 65,535). The tool slices your text to 65,535 characters before encoding, so anything beyond is dropped. For long text, store it inside the archive as a file rather than in the comment.
Multibyte comment exceeds 65,535 bytes after UTF-8 encoding
Length-field caveatThe slice is by character count, not byte count, so a comment under 65,535 characters but with many multibyte characters could encode to more than 65,535 bytes — beyond what the 2-byte length field can represent. Keep non-ASCII comments well under the limit; for ASCII text, 65,535 characters equals 65,535 bytes and is safe.
ZIP has no existing comment
SupportedAdding a comment to a ZIP that had none is the normal case — the previous comment length was 0, and the tool simply writes the new length and bytes. Nothing about the existing data changes.
Leaving the textarea empty on a ZIP that already had no comment
By designThe output is effectively identical to the input (comment length stays 0). The result metric Removed? reports true. This is a no-op for the comment but the file is re-downloaded as <name>-with-comment.zip.
Archive comment contains data after the EOCD that is not a comment
OverwrittenSome self-extracting or appended-data ZIPs store extra bytes after the EOCD. The tool treats everything after the 22-byte EOCD header as the comment region and overwrites it. If your file relies on trailing data outside the comment, do not use this tool on it.
Corrupt ZIP where the EOCD signature is missing
ErrorIf PK\x05\x06 cannot be found in the last 65,557 bytes, the comment cannot be located and the edit fails. Try corrupted-zip-repair to rebuild the central directory first.
ZIP64 archive (very large or many entries)
SupportedZIP64 files still carry a standard EOCD record (with placeholder fields) plus a ZIP64 EOCD locator. The tool finds the standard EOCD and edits its comment normally; the ZIP64 structures earlier in the file are untouched.
File over the tier size limit
RejectedA ZIP larger than your tier's cap (50 MB Free, 500 MB Pro, 2 GB Pro-media/Developer) is rejected before processing. Comment editing reads the whole file into memory, so the size cap is enforced up front.
Frequently asked questions
Will editing the comment break my ZIP?
No. The EOCD comment is a free-form trailing field that no entry depends on, and every unzipper safely ignores it. The tool recomputes the 2-byte comment-length field so the EOCD stays valid, and it copies all entry data and the central directory byte-for-byte. Your file list and contents are unchanged.
Does this re-compress my files?
No. Unlike re-zipping, this tool does not decompress or re-compress anything. It keeps everything up to and including the EOCD header, then rewrites only the trailing comment. Every compressed entry is byte-identical to the source.
How do I remove a comment?
Leave the textarea empty and run the edit. The comment-length field is set to 0 and the trailing text is removed. The result metric Removed? will report true.
Can I add a comment longer than 65,535 characters?
Standard ZIP caps the comment at a 2-byte length field, so 65,535 bytes is the maximum. The tool slices longer text to 65,535 characters before encoding. For anything bigger, store the text as a file inside the archive instead.
Does the comment support emoji or non-ASCII text?
Yes — the comment is encoded as UTF-8, so accented characters and emoji are preserved. Most modern unzippers display them correctly; very old DOS-era tools may show mojibake. Keep multibyte comments short so the encoded byte count stays within the limit.
Can I edit the comment on a .docx, .xlsx, or .apk?
Yes. Those formats are ZIP containers with a valid EOCD, so the editor works on them. Editing the comment does not affect how Word, Excel, or Android reads the file, because they ignore the EOCD comment.
Why does it say 'Not a valid ZIP archive'?
The file has no End of Central Directory record. That happens with non-ZIP formats (7z, rar, tar, gzip) or with a corrupt ZIP whose EOCD is missing. Convert to ZIP first, or try corrupted-zip-repair if the file should be a ZIP.
Can I view the existing comment before editing?
Not in this tool — it only writes a new comment. To read an existing global comment, use the comment-extractor at /archive-tools/comment-extractor, then come back here to change it.
Does it append to the existing comment or replace it?
It replaces. Whatever you type becomes the entire new comment; there is no append or prepend mode. If you want to keep part of the old comment, copy it from comment-extractor and re-type it together with your additions.
Is my file uploaded anywhere?
No. The edit runs entirely in your browser. The ZIP bytes are read locally, modified in memory, and downloaded — nothing is sent to a server.
What is the output filename?
The download is named <original-stem>-with-comment.zip regardless of whether you added or removed the comment. Rename it back if you are working with a ZIP-container format like .docx.
What size files can I process?
Free handles up to 50 MB and 500 entries per archive. Pro raises this to 500 MB / 50,000 entries, and Pro-media or Developer to 2 GB / 500,000 entries. The whole file is loaded into memory for the edit, so the size cap is enforced before 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.