Start with a copy of the archive
Keep the original ZIP before attempting recovery. A broken archive may still contain complete individual files even when its central directory or final footer is missing. Those directory records normally tell an archive reader where members are stored. This desk also reads surviving local headers, checks their declared lengths and verifies actual decompressed bytes against each member’s CRC-32.
Choose your ZIP or run the built-in example. The example is a real archive generated in the browser with its central directory removed and one member deliberately damaged. Two intact files can be recovered, while the damaged member fails its checksum. The result demonstrates the same parser and output path used for your own file.
Read the evidence before downloading
The inventory separates verified files, failed members, skipped unsupported cases and empty directory markers. A verified file has passed the supported header, size, path, decompression and CRC checks. A failed file has not. A skipped file may contain data, but this implementation cannot safely include it under its declared limits or supported format rules.
The central-directory status describes the available indexing evidence. If no complete directory exists, recovery follows local member boundaries until an ambiguous or truncated header prevents safe progress. It does not search arbitrary compressed bytes for header-like patterns and pretend they identify real files. Later members can therefore remain uninspected even when some bytes are still present.
Keep a reviewable recovery package
Download the new verified ZIP, the JSON or CSV evidence and the unchanged original. The new archive contains only the verified files, with fresh ZIP metadata. It does not preserve original timestamps, comments, permissions, archive signatures or every extra field. Empty directory markers are not exported on their own, although folder paths belonging to recovered files remain usable.
Open representative recovered files in the appropriate application and compare them with a backup, expected filenames or other trusted records. A matching CRC is useful evidence against accidental corruption, but it is not authentication, malware screening or proof that the whole original archive was recovered. Missing or overwritten bytes require another source; this tool does not invent their contents.