How to zip repair in developer workflows
- Step 1Grab the broken artifact — Download the corrupt ZIP locally — a failed release asset, a CI cache, or a dependency archive. The tool reads it from disk; nothing uploads.
- Step 2Open the repair tool — Go to /archive-tools/corrupted-zip-repair (Pro plan or higher). Drop the single ZIP. There are no settings to configure — recovery is fixed.
- Step 3Process and read the report — Click Process. The result panel shows Attempts, Recovered, and Recovery rate so you know immediately whether the artifact is salvageable enough to use.
- Step 4Make it reproducible — If you need bit-stable output, pass the repaired ZIP through Timestamp Normalizer with the 1980-01-01 ZIP epoch to zero out per-entry timestamps.
- Step 5Attest the result — Generate a SHA-256 manifest with Checksum Generator so a later build or a reviewer can verify the salvaged artifact.
- Step 6Diff against a known-good build — Run Archive Diff over the repaired ZIP and a reference build to confirm which entries actually survived and whether anything is missing.
Browser repair vs CLI in dev workflows
JAD's repair is UI-only; CLIs cover the automated cases.
| Need | Use JAD repair? | Alternative |
|---|---|---|
| Quick rescue of one broken artifact | Yes | — |
| Inspect an artifact without checking out a branch | Yes | — |
| Repair as a CI step | No (no API) | zip -FF in the pipeline |
| Batch-repair many ZIPs | No (single-file) | Script a CLI loop |
| Files over 2 GB | No (RAM-bound) | zip -FF / 7z streaming |
| Reproducible salvaged output | Yes (+ Timestamp Normalizer) | zip --latest-time then strip |
Reproducible-output pipeline
Chain the repaired ZIP through these to get a bit-stable, attestable artifact.
| Step | Tool | Effect |
|---|---|---|
| 1. Recover | /archive-tools/corrupted-zip-repair | Salvage entries into a fresh ZIP |
| 2. Normalize time | /archive-tools/timestamp-normalizer | Set all entries to 1980-01-01 (ZIP epoch) |
| 3. Attest | /archive-tools/checksum-generator | Emit a SHA-256 manifest |
| 4. Diff (optional) | /archive-tools/archive-diff | Compare against a known-good build |
Cookbook
Developer-shaped recipes — rescuing artifacts, making output reproducible, and confirming what survived.
Rescue a failed release asset
A GitHub release ZIP won't unzip after an interrupted upload. The payloads are intact; the index is not.
Input: app-v2.4.1.zip ("end-of-central-directory not found")
Process -> Corrupted ZIP Repair
Attempts 96 / Recovered 96 / 100%
Output: app-v2.4.1-repaired.zip -> re-upload the fixed assetMake the salvaged ZIP reproducible
After recovery you want a deterministic artifact for the build cache.
1. corrupted-zip-repair -> dist-repaired.zip 2. timestamp-normalizer (target 1980-01-01) -> dist-repaired-normalized.zip (all entry times zeroed) 3. checksum-generator -> dist.sha256 manifest Same bytes on every machine; manifest pins the result.
Confirm what actually survived
A truncated CI cache recovers partially; you need to know which entries are missing.
Process -> Attempts 1,204 / Recovered 1,190 / 98% Diff: archive-diff (dist-repaired.zip vs known-good dist.zip) -> 14 entries present in good build, missing in repaired Decide: rebuild the 14, or accept the partial cache.
Triage a mislabeled dependency
A vendored .zip is actually a tarball. The repair tool tells you fast.
Process -> "No recoverable local file headers found..." auto-format-detector -> reports gzip/tar Fix: rename to .tar.gz and use the right extractor.
Inspect a PR artifact without checkout
A PR ships a binary ZIP artifact you want to peek at without pulling the branch.
Download the artifact -> corrupted-zip-repair (if it won't open) -> repaired ZIP, report shows what's inside Then: archive-integrity-tester to confirm CRCs before trusting it.
Edge cases and what actually happens
No public API
Not automatableArchive tools have no programmatic endpoint (apiAvailable is false). The repair tool cannot be a CI step. Paid tiers can route through a local headless-browser runner, but for pipelines use a CLI like zip -FF.
Single file only
By designThe repair tool processes one ZIP per run — it is not generative, multi-file, or dual-file. To repair many archives, script a CLI loop instead.
Output is recompressed
By designThe repaired ZIP is rebuilt with fflate at deflate level 6, not a byte-copy. Extracted contents are identical, but the ZIP bytes differ. For reproducibility, normalize timestamps and pin a manifest.
Entry order changes
ExpectedRecovered entries follow byte-scan order, not the original directory order. A naive byte-diff of two repaired ZIPs may differ even with identical contents; diff extracted trees or use Archive Diff instead.
Encrypted artifact entries
SkippedEntries with the encryption flag set are skipped — there is no password field. Encrypted build artifacts need the password and a tool that supports it.
Truncated CI cache
Partial recoveryThe final entry whose data runs past end-of-file is skipped; everything before it recovers. Use Archive Diff against a known-good build to find the gap.
Over the tier limit
Error: tier limitFiles past 500 MB (Pro) or 2 GB (Pro-Media / Developer) throw a tier-limit error. Large monorepo artifacts may need a streaming CLI.
Not actually a ZIP
Error: no headersA mislabeled tarball or 7z yields no PK headers and errors out. Confirm the real format with Auto Format Detector before using the repair tool.
Frequently asked questions
Is there a CLI or API for the repair tool?
There is no public API — archive tools have apiAvailable set to false. The closest scriptable equivalents are zip -FF (Info-ZIP) and 7z. JAD wraps the same local-header scan behind a browser UI for one-off rescues.
Can I repair artifacts in CI?
Not with this tool directly. It is UI-driven and single-file. For pipelines, run zip -FF or a 7z loop. Use the browser tool for ad-hoc rescues during development or review.
How do I make the salvaged output reproducible?
Run the repair, then pass the result through Timestamp Normalizer with the 1980-01-01 ZIP epoch, then generate a SHA-256 manifest with Checksum Generator. That yields bit-stable output a later build can verify.
Why does a byte-diff of two repaired ZIPs differ?
Recovered entries are written in byte-scan order and recompressed at deflate level 6, so the container bytes can differ even with identical contents. Diff the extracted trees or use Archive Diff instead of comparing raw ZIP bytes.
Can I batch-repair many artifacts?
Not in this tool — it processes one file per run. Script a CLI loop for bulk repair. JAD's batch-oriented archive tools are for extraction and reporting, not repair.
Does the repaired ZIP work with my existing tooling?
Yes. It is a standard ZIP with no JAD-specific wrapper or metadata — open it with unzip, 7z, or any consumer and drop it into your build step.
What if only some entries are recovered?
The recovery rate tells you the fraction salvaged. Run Archive Diff against a known-good build to identify exactly which entries are missing, then rebuild those.
Can it repair encrypted artifacts?
No. Encrypted entries are skipped because there is no password field. Use a tool that accepts the password for those.
How large an artifact can it handle?
Up to 500 MB on Pro and 2 GB on Pro-Media / Developer. The whole file is held in RAM during the scan, so very large monorepo artifacts may need a streaming CLI.
Does the runner change the result?
Paid tiers may route the job to a local headless-browser runner, but the recovery algorithm is identical — same salvaged entry set, same report. The runner just executes the same code outside the page.
Can I confirm an artifact's contents before trusting it?
Yes. After repair, run Archive Integrity Tester to confirm per-entry CRCs, and File Listing Generator if you want a manifest of what is inside.
Is it ZIP-only?
Yes. The scan understands ZIP local headers only. A tarball, 7z, or gzip artifact returns the no-headers error — use Auto Format Detector to identify and re-route those.
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.