How to archive diff vs cli tools (diff -r, unzip -l, cmp)
- Step 1Decide on scope: entries vs contents — If you need 'which files differ', the browser diff or
diff -rboth answer it. If you need 'what changed inside file X', you need a content diff (diff fileA fileB) on the extracted entries — the archive diff only points you at the file. - Step 2Decide on format — Browser Archive Diff is ZIP-only (it reads ZIP central directories). For TAR/7z/RAR comparisons on the command line, list with the matching tool (
tar -tzf,7z l) and diff the listings, or re-zip and use the browser tool. - Step 3Decide on privacy and install constraints — Both the browser tool and local CLI keep data on your machine. The browser path needs no install, no temp-write permission, and no shell — handy on managed corporate laptops.
- Step 4Decide on scale — Under ~500 MB the browser tool is instant because it never decompresses. Over 2 GB, or for thousands of archives in a loop, a scripted CLI pipeline is the right tool.
- Step 5Pick the matching JAD tool when you need more — Need content hashes for attestation? Use Per-File Checksum Generator. Need to know storage overlap? Use Redundancy Analyzer. Need a single-archive listing? Use File Listing Generator.
- Step 6Run the browser diff — Drop archive A and archive B at /archive-tools/archive-diff and click Process — you get the four-bucket report without touching a terminal.
Approach-by-approach comparison
Comparing two ZIPs four ways. 'Browser Archive Diff' is JAD's tool; the rest are common command-line patterns.
| Approach | Needs extraction? | Compares by | Ignores timestamp noise? | Best for |
|---|---|---|---|---|
| Browser Archive Diff | No | Entry name + CRC32 (from central dir) | Yes (CRC32 is content-only) | Quick 'what files differ' on ZIPs, no install |
diff -r on extracted trees | Yes (both) | File contents byte-for-byte | Yes for content, but slow | Content-level diffs of small trees |
unzip -l listing diff | No | Name + size + date text | No (dates create false diffs) | Quick listing sanity check |
cmp per file | Yes (the files) | Bytes of one file pair | Yes | Confirming a single file is identical |
When to use which
Pick by the constraint that dominates your task.
| Your situation | Recommended approach |
|---|---|
| Two ZIPs under 2 GB, want the changed-file list fast | Browser Archive Diff |
| No shell / no install allowed | Browser Archive Diff |
| Need to see the lines that changed inside a file | Extract changed entries, then diff fileA fileB |
| Archives are 7z / RAR / TAR.GZ | List with the matching CLI, or re-zip then browser diff |
| Thousands of archives in a nightly job | Scripted CLI pipeline |
| Need cryptographic content proof, not CRC32 | Per-File Checksum Generator (SHA-256) |
Cookbook
The same comparison done the CLI way and the JAD way, so you can see exactly where each shines.
diff -r vs browser diff: the same answer, very different cost
diff -r requires unpacking both ZIPs to temp dirs first. The browser diff reads the central directories and never decompresses, so it's far faster for the same 'which files differ' answer.
# CLI: extract both, then recursive diff unzip -q app-old.zip -d /tmp/old unzip -q app-new.zip -d /tmp/new diff -rq /tmp/old /tmp/new Files /tmp/old/dist/app.js and /tmp/new/dist/app.js differ Only in /tmp/new/dist: feature.js # JAD: drop both, click Process Diff summary Added: 1, Removed: 0, Changed: 1, Unchanged: 410
Why unzip -l listing diffs are noisy
An unzip -l listing includes dates, so two builds of the same source diff on every line even when content is identical. The browser diff compares CRC32, so identical content stays Unchanged.
# unzip -l includes the date column → every line 'differs' diff <(unzip -l a.zip) <(unzip -l b.zip) < 2026-06-12 09:01 src/app.js > 2026-06-13 11:44 src/app.js (date only — content identical!) # JAD compares CRC32, not dates Diff summary Added: 0, Removed: 0, Changed: 0, Unchanged: 322
Confirming a single file with cmp vs reading the Changed bucket
cmp answers 'is this one file identical' for an extracted pair. The browser diff answers it for every file at once, then you cmp only the ones in Changed.
# cmp: one pair at a time cmp /tmp/old/config.json /tmp/new/config.json config.json differ: byte 88, line 4 # JAD: the Changed bucket is your cmp shortlist ~ Changed (1) ~ config.json ← extract just this one and inspect
Cross-format: the browser tool is ZIP-only
Diffing a .tar.gz against a .zip on the CLI means listing each with its own tool. The browser diff reads ZIP central directories only, so re-zip the TAR tree first or compare listings on the command line.
# CLI cross-format listing diff diff <(tar -tzf build.tar.gz | sort) <(unzip -Z1 build.zip | sort) < ./bin/run.sh > bin/run.sh (path-prefix difference, not a real change) # JAD path: re-zip the tar tree, then diff two ZIPs
Scale: where CLI takes over
For a one-off pair under 2 GB the browser tool is instant. For a nightly job over hundreds of archives, a shell loop with checksums is the right tool — and the browser diff is the manual fallback when something looks off.
# Nightly CLI loop (illustrative) for z in releases/*.zip; do unzip -Z1 "$z" | sort | sha256sum >> manifest.txt done # Then when one manifest changes, open the two ZIPs in JAD # to see the exact added/removed/changed entries.
Edge cases and what actually happens
You expected a content diff
By designThe browser tool is an archive-level diff: it reports which entries differ, not which lines. For line-level changes, extract the entries in the Changed bucket and run diff or cmp on them.
Comparing a ZIP against a TAR.GZ
Zero entriesThe diff engine parses ZIP central directories only, so a TAR.GZ side yields zero entries and everything reads as added/removed. On the CLI you'd diff the two listings instead; in JAD, re-zip the TAR tree first.
Path-prefix mismatch (./bin vs bin)
ExpectedLike a listing diff, name matching is exact. ./bin/run.sh and bin/run.sh are different names, so the file shows as Removed plus Added. Normalise prefixes with Path Prefix Remover before diffing.
Timestamp-only differences
UnchangedWhere unzip -l listing diffs flag every changed date, the browser diff compares CRC32 (content only). Files that differ only in timestamp stay in the Unchanged bucket — a real advantage for reproducible-build checks.
Archive larger than 2 GB
Tier limitThe browser tool caps at 2 GB per archive (Pro+Media / Developer). Beyond that, a scripted CLI pipeline is the right approach — browser memory becomes the constraint.
CRC32 vs cryptographic equality
NoteCRC32 catches accidental change reliably but isn't collision-resistant against an adversary. Where sha256sum would be your CLI choice for tamper-evidence, use Per-File Checksum Generator alongside the diff.
Renamed file
ExpectedNeither diff -r nor the browser diff pairs files by content across different names — a rename shows as a delete plus an add in both. Content-similarity rename detection is out of scope for both.
One archive's central directory is corrupt
Zero entriesWhere unzip -l would error loudly, the browser parser quietly returns zero entries for an unreadable ZIP. Validate suspect archives with Archive Integrity Tester first.
Frequently asked questions
Is the browser diff as accurate as diff -r?
For 'which files differ', yes — and it's stricter than a listing diff because it compares CRC32 content checksums, not dates or sizes. For 'what changed inside a file', diff -r (on extracted files) is what you want; the browser tool points you at the files to inspect.
Does it compare file contents like cmp?
It compares the CRC32 of each entry, which is derived from the content. Same CRC32 means the bytes match; different CRC32 means they differ. It doesn't show you the differing bytes the way cmp does — extract the changed entry for that.
Why is CRC32 better than a unzip -l listing diff?
unzip -l includes dates and sizes, so two builds of identical source 'differ' on every line. CRC32 reflects content only, so timestamp-only changes stay in Unchanged. The browser diff gives a cleaner signal.
Can it diff TAR, 7z, or RAR like the CLI?
No. The diff engine reads ZIP central directories. For other formats, diff their listings on the command line (tar -tzf, 7z l) or re-zip the tree and use the browser tool.
Is the browser tool slower than CLI?
Usually faster for ZIPs under ~500 MB, because it never decompresses — it reads the central directory and compares checksums. CLI overtakes it on multi-GB archives and on scripted batches.
Does it need temp disk space like diff -r?
No. diff -r extracts both archives to disk first; the browser diff reads metadata in memory and writes nothing to disk except the optional downloaded report.
Is it private, like running diff locally?
Yes. The diff runs in your browser tab; the archives are never uploaded. It's the privacy equivalent of running a local CLI, with no install required.
What output format do I get?
An HTML report with the four bucket counts and colour-coded lists, downloadable as diff-A-vs-B.html. CLI tools give you plain text you'd reformat by hand; the HTML is ready to attach to a PR.
Can I script the browser tool in CI?
Not today — there's no public API for it. For CI, script unzip -Z1 + sha256sum (or fflate in Node), and use the browser tool for the manual investigation when a manifest changes.
How does it handle renames vs diff -r?
Identically: both show a rename as a delete plus an add, because neither pairs files by content across different paths.
What about path-prefix differences?
Exact-name matching means ./bin/x and bin/x differ, just like a sorted listing diff would. Normalise with Path Prefix Remover before comparing.
When is the CLI strictly better?
Archives over 2 GB, non-ZIP formats, scripted batch jobs, and content-level line diffs. For everything else — quick, private, install-free ZIP comparison — the browser tool is the faster path.
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.