Compare Two ZIP Files

This tool answers one narrow question well: given two ZIP archives, which entries appear in one but not the other, and which entries share a path but differ in size. It loads Archive A (the original or older copy) and Archive B (the updated or newer copy) and sorts every entry 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.

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 or dropped. For students and admin staff, it can confirm that a resubmitted or re-sent ZIP matches an earlier one by file inventory, and for anyone sharing archives, it gives a quick read on whether a received copy has the same set of 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 an inventory-level diff, not a content merge tool, so reach for it when the question is "what files moved" 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 with a ZIP library, their entry 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. You can then Export CSV to save a row-per-file report with the status, path, and the A and B sizes.

Matching is done by full file path. An entry whose path exists only in B is Added; one whose path exists only in A is Removed; a path present in both is marked Changed when its uncompressed size differs and Same when it matches. Input is ZIP only, with a 200 MB limit per file, and the deliverable is the on-screen tables plus the CSV export.

What it does not do is read inside files. It performs no byte-level or content diff, no checksum comparison, and no line-by-line text comparison. Two files at the same path with identical sizes are reported as Same even if their bytes differ, and it will not merge archives, show you the actual edits, or produce a combined ZIP.

The central limitation is that "Same" means "same path and same uncompressed size," not "identical content." An edit that leaves a file exactly the same size — swapping one character for another, replacing an image with a different one of equal byte count — will be reported as unchanged. Conversely, a file flagged Changed only tells you the size moved; it does not tell you what or why. If you need certainty that content is identical, pair this with a checksum tool rather than trusting the Same bucket alone.

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 TXT export — the working 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, confirm the old-to-new size shift is plausible for the edit you believe was made.

Remember the blind spot when reviewing the Same group: equal size does not prove equal content. If a file in that bucket matters, verify it independently — a checksum or hash comparison is the reliable way to confirm two same-sized files are truly identical. 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 resized, but a manual, content-level review of the affected files (and a checksum check on anything reported as unchanged) is required before you certify that two archives are equivalent.