Compare Two ZIP Files

This tool answers one narrow question well: given two ZIP archives, which files appear in one but not the other, and which share a path but have different content. It loads Archive A (the original or older copy) and Archive B (the updated or newer copy) and sorts every file into Added, Removed, Changed, or Same. That makes it a fit for backup verification, where you confirm a fresh backup still contains the files an older one had and flag anything that silently vanished or changed.

It also suits version review on real deliverables: comparing two project hand-offs to a client, checking what a contractor altered between drafts, or auditing two builds of a static site bundle to see which assets were added, dropped or modified. For students and admin staff, it can confirm that a resubmitted or re-sent ZIP matches an earlier one, and for anyone sharing archives, it gives a quick read on whether a received copy holds the same files as the one that was sent.

Because everything runs locally, it is reasonable to point it at archives you would not upload to a third party (internal backups, client work, or coursework), without those files leaving your machine. The output is a file-level diff, not a content merge tool, so reach for it when the question is "which files differ" rather than "what text changed inside a file."

Drop or select a ZIP into each of the two slots (Archive A on the left, Archive B on the right) then press Compare archives. Both files are read in your browser, their file lists are built, and the diff is computed on the spot. You get a four-count summary (Added, Removed, Changed, Same) followed by scrollable lists showing each affected path with its size, and for changed files the old size next to the new one. Export CSV saves a row-per-file report with the status, path, and the A and B sizes in bytes. Replacing either archive clears the previous result, so a comparison is never shown against the wrong pair.

Matching is done by full file path. A path that exists only in B is Added; one that exists only in A is Removed. A path present in both is Changed when its uncompressed size differs or when its CRC-32 differs; that is the checksum of the file's content that every ZIP stores, so the comparison catches an edit even when the size stays exactly the same. Input is ZIP only, with a 200 MB limit per file.

What it does not do is show the edits themselves. There is no line-by-line text comparison, it will not merge archives or produce a combined ZIP, and password-protected ZIPs cannot be read (the tool says so).

CRC-32 is designed to catch accidental changes, and it does that reliably: a corrupted, re-saved or edited file will almost certainly show as Changed. It is not designed to resist deliberate forgery, because someone determined can craft a different file with the same CRC-32. If you need to prove that nobody tampered with a file, compare SHA-256 checksums with the Checksum tool instead.

Path sensitivity is the other common trap. Because matching is exact-path, a file that was merely moved or renamed shows up as one Removed plus one Added, not as a single change. Differences in folder nesting between the two archives, for example one ZIP wrapping everything in an extra top-level folder, or Mac-created __MACOSX and .DS_Store entries, will inflate the Added and Removed counts with paths that are really the same content in a different place.

Smaller mistakes to avoid: loading the archives in the wrong order, since A is treated as the original and B as the new version, which flips the meaning of Added and Removed; and expecting a TXT export, since the report format here is CSV. Non-ZIP archives such as RAR, 7z, or TAR are not accepted, and very large archives near the 200 MB ceiling depend on your device's available memory.

Start with the four summary counts and sanity-check them against what you expected to change. Open the Added and Removed lists and scan for paths that look like the same file in a different location; a move or rename will appear in both lists, and __MACOSX or .DS_Store noise will pad them; treat those as artifacts rather than real differences. In the Changed list, a file whose size did not move changed content of the same length, which is worth a closer look.

Export the CSV if you want a durable record of the comparison or need to share the file-level breakdown with someone else.

For any official, financial, or legal use (a contract bundle, a regulatory submission, an audited deliverable), do not treat this diff as authoritative on its own. It establishes which files were added, removed, or changed, but a manual, content-level review of the affected files, and SHA-256 checksums where tampering is a concern, is required before you certify that two archives are equivalent.