How to zip comment editor in developer workflows
- Step 1Decide browser vs CI — For a one-off stamp or to fix a bad comment on a built artifact, use the browser tool. For every build, automate with
zip -zin your pipeline — the browser tool has no headless API and cannot run in CI. - Step 2Read the current comment first (optional) — Use comment-extractor at /archive-tools/comment-extractor (or
unzip -z artifact.zip) to see what's there. This tool replaces rather than appends, so you need the existing text if you want to keep part of it. - Step 3Compose your stamp — A typical stamp:
app v1.2.3 | sha 9f3a1c2 | 2026-06-10. Keep it under 65,535 bytes (rarely a concern for a one-line stamp). - Step 4Edit in the browser — Drop the ZIP, paste the stamp into the single textarea (or leave it empty to strip a leaked comment), and download
<name>-with-comment.zip. - Step 5Verify the entry data is unchanged — Confirm with
unzip -l(file list identical) and, for reproducible builds, re-hash the extracted files — they match the pre-edit hashes because nothing was re-compressed. - Step 6Mirror it in CI with the CLI — In your pipeline, run
printf 'app v1.2.3 | sha %s | %s' "$GIT_SHA" "$(date -u +%F)" | zip -z artifact.zipto stamp on every build the same in-place way.
Browser tool vs CI script
When to use the interactive browser editor versus a scripted CLI in your pipeline.
| Need | Use | Why |
|---|---|---|
| One-off stamp / triage | Browser tool | No install, instant, UTF-8 by default |
| Fix a bad comment on a built artifact | Browser tool | Drop, retype, download — faster than re-running the build |
| Stamp on every build | zip -z in CI | Browser tool has no headless API |
| Reproducible-build hashing | Either (both in-place) | Entry bytes unchanged, so content hashes hold |
| Strip a leaked CI path/username | Browser tool | Empty textarea clears the comment in one action |
Comment edit vs re-archiving
Why in-place editing matters for build pipelines.
| Aspect | This tool (in-place) | Re-zip / repackage |
|---|---|---|
| Entry compressed bytes | Unchanged | Rewritten (re-compressed) |
| Per-file content hash | Stable | May change |
| Whole-file hash | Changes by comment delta only | Changes entirely |
| Detached signature over entries | Still valid | Likely invalid |
| Build reproducibility | Preserved | At risk |
Tier limits for artifacts
Pick a tier that covers your largest release ZIP. Limits are per archive.
| Tier | Max file size | Max entries | 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
Browser steps paired with the CI-friendly CLI equivalent so the same in-place edit happens locally and in your pipeline.
Stamp a release with version + commit SHA
Add a build marker visible to anyone who inspects the archive comment, without touching the contents.
Browser: drop app-1.2.3.zip → type:
app v1.2.3 | sha 9f3a1c2 | 2026-06-10
→ download app-1.2.3-with-comment.zip
Verify: unzip -z app-1.2.3-with-comment.zip
→ app v1.2.3 | sha 9f3a1c2 | 2026-06-10
CI equivalent:
printf 'app v1.2.3 | sha %s | %s' "$SHA" "$(date -u +%F)" \
| zip -z app-1.2.3.zipStrip a leaked CI path from a comment
A packaging step wrote the runner's working directory into the comment. Clear it before publishing.
unzip -z artifact.zip → packed from /home/runner/work/app/app by github-actions Browser: drop artifact.zip → leave textarea empty → download Removed?: true CI: printf '' | zip -z artifact.zip
Prove reproducible-build hashes hold
Show that the content hash is stable across the comment edit — only the whole-file hash moves.
Before: extract → sha256sum * > before.txt; sha256sum artifact.zip Edit comment (browser or zip -z) After: extract → sha256sum * > after.txt; sha256sum artifact.zip diff before.txt after.txt → no differences (content stable) whole-file hash: changed (comment delta only)
Replace a wrong build number
A bad pipeline run stamped the wrong version. Fix it on the built artifact without rebuilding.
Old comment: app v1.2.2 | sha 9f3a1c2 Browser: drop → retype: app v1.2.3 | sha 9f3a1c2 | hotfix (no append mode — full replace; copy old text first if needed)
Stamp a .jar without re-jarring
JARs are ZIPs, so you can stamp them in place — handy when re-running the Java build is slow or non-deterministic.
Input: service.jar (ZIP container) Comment: service v3.1 | built by CI #4821 | 2026-06-10 Download service-with-comment.zip → rename to service.jar Manifest and class bytes untouched; only the EOCD comment changes.
Edge cases and what actually happens
Trying to run the browser tool in CI
Not supportedThe browser editor is interactive with no headless API, so it cannot run in a pipeline. Use zip -z (Info-ZIP) in your CI runner for the same in-place comment edit on every build.
Comment replaces instead of appending
By designTyping a new comment overwrites the old one entirely. If your build appends to an existing stamp, read the current comment with comment-extractor first and re-type the combined text — there is no append mode.
Long SHA + message exceeds 65,535 bytes
TruncatedUnlikely for a one-line stamp, but the comment caps at 65,535 bytes (the tool slices to 65,535 characters). Keep stamps concise; store full changelogs as a file inside the archive instead.
Re-archiving step elsewhere in the pipeline breaks reproducibility
Hash mismatchThis tool keeps entry bytes stable, but if a later step re-zips the artifact, content hashes can shift. Stamp the comment last, after the final archive is built, to keep reproducible-build hashes intact.
Artifact is a .tar.gz or .7z
RejectedThose formats have no EOCD comment. The tool errors on non-ZIP input. Stamp ZIP/JAR artifacts here; for tar/7z, record build metadata in a sidecar file or your release notes.
Output filename differs from input
ExpectedThe download is <stem>-with-comment.zip. In CI you control the name with the CLI; in the browser, rename if your release process expects the original filename (e.g. restoring a .jar extension).
Office/zip-container artifact stamped, then opened
SupportedStamping a .docx/.xlsx/.jar/.apk only changes the EOCD comment; the application ignores it and opens the file normally. Rename the extension back after download.
Artifact larger than the tier cap
RejectedThe whole file is read into memory, so a ZIP over your tier's size cap (50 MB Free / 500 MB Pro / 2 GB above) is rejected before editing. Use a tier that covers your release size.
Frequently asked questions
Can I run this in my CI pipeline?
Not the browser tool — it is interactive with no headless API. For CI, use zip -z (Info-ZIP), e.g. printf 'v1.2.3 sha $SHA' | zip -z artifact.zip. It performs the same in-place comment edit. Use the browser tool for one-off stamping and triage.
Will stamping the comment break reproducible builds?
No, as long as you stamp last. The tool does not re-compress entries, so per-file content hashes are unchanged. Only the whole-file hash moves, by exactly the comment delta. Stamp after the final archive is built.
Does it append to my existing build stamp?
No — it replaces the whole comment. If you want to extend an existing stamp, read it with comment-extractor first and re-type the combined text.
How do I strip a leaked CI path from a comment?
Leave the textarea empty and run the edit; the comment-length field is set to 0 and the leaked text is removed (Removed? shows true). In CI, printf '' | zip -z artifact.zip does the same.
Can I stamp a JAR or APK?
Yes — both are ZIP containers. Stamp them in place, download <name>-with-comment.zip, and rename the extension back. Manifests, class files, and signature blocks are untouched.
What's the maximum comment length?
65,535 bytes, the ZIP format limit (a 2-byte length field). The tool slices longer text to 65,535 characters. A one-line build stamp is far below this; store full changelogs as a file inside the archive.
How do I verify the stamp landed?
Run unzip -z artifact.zip to print the comment, or read it back with comment-extractor. Confirm contents are unchanged with unzip -l.
Why does my whole-file hash change but content hashes don't?
Because only the trailing EOCD comment and its 2-byte length field change. The compressed entries are byte-identical, so extracted-file hashes match; the whole-file hash differs by the size of the comment change.
Can it stamp a .tar.gz?
No — tar and gzip have no ZIP-style global comment, so the tool rejects them. Record build metadata in a sidecar file or your release notes for those formats.
Is UTF-8 safe for commit messages with non-ASCII?
Yes. The comment is always UTF-8 encoded, so non-ASCII characters and emoji survive. Keep multibyte text short so the encoded byte count stays under 65,535.
What is the output filename?
<original-stem>-with-comment.zip. In CI you set the name yourself with the CLI; in the browser, rename after download if your release process needs the original name.
Where do I check the archive's other metadata?
Use archive-metadata-extractor at /archive-tools/archive-metadata-extractor for EOCD fields, entry counts, and central-directory details, and timestamp-normalizer if you also need deterministic entry timestamps for reproducible builds.
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.