What this repair actually rebuilds
ZIP files keep metadata beside each stored file and again in a central directory near the end of the archive. When that final directory is lost, many extractors reject the whole ZIP even though the file records themselves still exist. MakeFileWork walks those local records, verifies recoverable payloads with declared sizes, decompression and CRC32, keeps only records that pass, and writes a new directory plus end record. If one bounded record is damaged but a later record remains independently verifiable, the repair can return a partial archive instead of discarding everything.
When recovery is deliberately refused
This repair does not trust ZIP signatures inside compressed bytes by themselves. It can recover streamed entries with either signed or signatureless ZIP data descriptors when declared sizes, decompression, CRC32 and the next ZIP boundary agree. A valid central directory provides exact descriptor offsets; if the directory is missing, signatureless records are accepted only at verified boundaries, never from a filename or ZIP signature alone. It still refuses to guess through encrypted or ambiguously streamed data, ZIP64 structures and unsafe boundaries. When a damaged entry has a trustworthy declared boundary, it can skip that entry and continue; when the boundary itself is unknowable, recovery stops there.
Word, Excel and PowerPoint
DOCX, XLSX and PPTX are ZIP-based containers. If the final ZIP directory is damaged but the local records survive, the tool can rebuild the container. It then checks content types, relationships and the main Word, Excel or PowerPoint XML part. For packages within the bounded inspection limits, it also verifies every indexed ZIP part with CRC32, including embedded media and binary attachments. A corrupt image or embedded object is not ignored merely because the main document XML is readable.
What a verified result means: local ZIP integrity and core OOXML consistency checks passed. This does not prove that Word, Excel or PowerPoint can open the file, that its layout is unchanged or that missing content was recovered. ZIP64, encrypted archives, unsupported compression and excessive decompression are refused rather than reported as successful repairs.
Hidden ZIP entries and active Office content
A DOCX, XLSX or PPTX can contain local ZIP records missing from its central directory. For a complete Office validation, the indexed records must cover the entire local ZIP payload without hidden prefixes, gaps or trailing records. A reconstruction that discovers extra entries or discards unindexed bytes is explicitly partial, not a verified complete recovery. Standard Office formats with macro or ActiveX parts are rejected by this conservative inspector. This is not an antivirus scan or a guarantee that a file is safe to execute.
Unsafe ZIP paths, duplicates and partial recovery
ZIP entries can contain traversal paths such as ../, absolute paths, reserved device names or filenames that collide after Unicode normalization and case folding. During repair, those entries are excluded rather than renamed or exported as if safe. The result is explicitly marked partial recovery, with an entry count and verification evidence. A mixed batch rejects partial ZIP recovery instead of silently delivering a file that may have lost content. Legitimate non-ASCII UTF-8 filenames remain supported; ambiguous legacy encodings are not guessed.
This path policy helps prevent unsafe extraction but does not scan files for malware or prove that recovered content is harmless. Review the partial recovery evidence before downloading and never extract unknown archives into sensitive folders.
Conflicting ZIP headers: why a file can be skipped
A ZIP entry has a local header and a separate central-directory record. Both must agree on its original filename, compression method, flags, CRC32 and sizes; streamed entries may use documented zero placeholders in the local header. If those records contradict one another, the tool does not silently choose a name or size. It excludes the conflicting entry and reports a partial recovery, while preserving independently verified files byte-for-byte. A damaged original directory also prevents a claim of complete index coverage. Mixed batches reject such partial repairs.
Preserving ZIP comments and permissions
A ZIP central directory can contain file comments, creator metadata, Unix file permissions, an archive comment and optional extra fields not stored in local file headers. For a consistent source directory, recovery now preserves entry comments, file attributes, creator versions and the archive comment byte-for-byte. Central-directory extra fields are deliberately not copied; if any are lost, the result is partial recovery and a mixed batch will not silently treat that reconstructed file as complete. Symlink entries and conflicting file-type metadata are excluded. A structural CRC check does not verify the safety of executable content.
How large a ZIP can be repaired locally?
The browser repair accepts ZIP inputs up to 40 MB, checks each recovered member against a 64 MB uncompressed limit, and caps total recovered uncompressed data at 128 MB across no more than 10,000 inspected entries. Deflate integrity is checked chunk by chunk with CRC32 and size accounting rather than keeping the entire expanded member in memory. The repaired archive still needs browser memory for the input and output; actual memory use depends on the device. An oversized or unverifiable archive is rejected, not reported as repaired.
Privacy
The current ZIP rebuild runs locally in your browser. Your archive is not uploaded by this workflow.