How to integrity tester vs unzip -t / 7z t
- Step 1Match the CLI command to the tool —
unzip -t file.zipand JAD's tester both verify ZIP entries against stored CRC32.7z t file.7zextends that to 7z/rar/tar and more. Use the browser tool for ZIP; reach for7z twhen the file isn't a ZIP. - Step 2Decide on privacy and install constraints — All three run locally — none uploads your archive. Pick the browser tool when you can't install software or don't want to copy the file anywhere; pick the CLI when it's already in your shell and the archive is on the same machine.
- Step 3Pick the output shape you need — Need to eyeball one file?
unzip -tis faster to read in a terminal. Need a structured artifact to attach to a ticket or feed a script? JAD's JSON report (totalEntries/passed/failed/results) is the cleaner format. - Step 4Handle encryption — For an encrypted ZIP, JAD takes the password in its password field and decrypts via zip.js before checking CRC32.
unzip -P pass -tand7z t -ppassdo the equivalent on the CLI. - Step 5Check the size budget — The CLI is bounded only by disk; JAD caps at 50 MB free, 500 MB Pro, 2 GB Pro-Media/Developer. For multi-GB archives the CLI is the practical choice.
- Step 6Interpret the result the same way everywhere — A CRC failure means the same thing in all three: that entry's bytes don't match its checksum. For tamper detection (not accidental corruption), step up to SHA-256 via checksum-generator.
Feature comparison
JAD's Archive Integrity Tester next to the two CLI tools people reach for. All three verify CRC32; the differences are scope, output, and friction.
| Capability | JAD Integrity Tester | unzip -t | 7z t |
|---|---|---|---|
| Core check | Per-entry CRC32 vs central directory | Per-entry CRC32 | Per-entry CRC (format-dependent) |
| Formats verified | ZIP (incl. AES-256 / ZipCrypto) | ZIP | 7z, ZIP, rar, tar, gz, xz, bz2, and more |
| Output | JSON report (results[], summary counts) | Terminal lines (OK / bad CRC) | Terminal summary |
| Install required | None — runs in browser | unzip package | p7zip / 7-Zip |
| Upload to a server | Never (local WASM) | Never (local) | Never (local) |
| Encrypted archives | Password field → zip.js | -P flag | -p flag |
| Max size | 50 MB free / 2 GB paid | Disk-bound | Disk-bound |
| Scriptable / pipeable | No shell pipe; JSON file out | Yes (exit code + text) | Yes (exit code + text) |
When to use which
Pick by situation, not by loyalty — most workflows use more than one.
| Situation | Best tool | Why |
|---|---|---|
| Locked-down laptop, no install rights | JAD Integrity Tester | Runs in any modern browser with no package install |
| Quick check of a colleague's download | JAD Integrity Tester | Drag, drop, read — no terminal needed, file never copied to a server |
| Need a structured artifact for a ticket | JAD Integrity Tester | JSON results array attaches cleanly; no log-parsing |
| File is a 7z, rar, or tar | 7z t | JAD verifies ZIP only; 7z t covers those formats |
| Multi-GB archive on a server | unzip -t / 7z t | No browser memory ceiling; archive already local |
| CI gate with exit codes | unzip -t / 7z t | Non-zero exit on failure pipes straight into a shell gate |
Cookbook
The same verification expressed three ways — CLI command, terminal output, and JAD's JSON report — so you can see they agree on the verdict.
Clean ZIP: unzip -t vs JAD report
An intact ZIP. unzip -t prints an OK line per entry and a 'No errors detected' footer; JAD returns the same verdict as structured JSON.
$ unzip -t release.zip
testing: bin/app OK
testing: lib/core.so OK
No errors detected in compressed data of release.zip.
JAD report (release-integrity.json):
{ "totalEntries": 2, "passed": 2, "failed": 0,
"results": [
{ "name": "bin/app", "storedCrc32": "a1b2c3d4", "passed": true },
{ "name": "lib/core.so", "storedCrc32": "9f8e7d6c", "passed": true } ] }Corrupt entry: bad CRC in both tools
unzip -t flags the broken entry with 'bad CRC'; JAD names the same entry as passed: false with the computed hash so you can confirm it's the file you think it is.
$ unzip -t photos.zip
testing: 2026/IMG_0421.jpg bad CRC 3c5a0f88 (should be 3c5a1f88)
At least one error was detected in photos.zip.
JAD report:
{ "name": "2026/IMG_0421.jpg",
"storedCrc32": "3c5a1f88",
"passed": false,
"error": "CRC mismatch: computed 3c5a0f88" }Encrypted ZIP with a password
Both tools take a password and verify the decrypted plaintext's CRC32. JAD uses the password field; the CLI uses a flag.
$ unzip -P 's3cret' -t secure.zip
testing: db.sql OK
No errors detected.
JAD: enter password in the password field, Process →
{ "totalEntries": 1, "passed": 1, "failed": 0 }
(7z equivalent: 7z t -p's3cret' secure.zip)A 7z file: where JAD stops and 7z t continues
JAD verifies ZIP only. Drop a 7z in and it rejects up front; 7z t handles it natively.
JAD: drop archive.7z → Error: "Not a valid ZIP archive." $ 7z t archive.7z 7-Zip ... Testing archive: archive.7z Everything is Ok Files: 128 Size: 41231004 Use JAD for ZIP; 7z t (or check format with /archive-tools/auto-format-detector first) for 7z.
Scripted gate vs. attached artifact
If you need a CI exit code, the CLI is the fit. If you need a human-readable artifact on a review ticket, JAD's JSON is cleaner — no log scraping.
CI gate (shell):
unzip -t build.zip > /dev/null && echo PASS || exit 1
Review artifact (JAD):
drop build.zip → download build-integrity.json →
attach to PR. Reviewer reads:
{ "totalEntries": 540, "passed": 540, "failed": 0 }
No terminal access required to read the result.Edge cases and what actually happens
Comparing on non-ZIP formats
Out of scope7z t verifies 7z, rar, tar, gz, xz, bz2 and more; JAD's tester verifies ZIP CRC32 specifically and rejects other formats with Not a valid ZIP archive. This isn't a parity gap to work around — it's the tool's deliberate scope. Detect the format with auto-format-detector and use the matching path.
Multi-GB archives
CLI winsThe CLI tools are bounded only by disk. JAD caps at 50 MB free, 500 MB Pro, and 2 GB on Pro-Media/Developer, with browser memory as a practical ceiling on huge archives. For a 5 GB ZIP, unzip -t is the right tool.
CI pipelines that key off exit codes
CLI winsunzip -t and 7z t return a non-zero exit code on failure, which drops straight into a shell &&/|| gate. JAD has no shell pipe and no public API — it produces a JSON file. For automation on Pro+, the @jadapps/runner can drive the tool in a headless browser, but a CLI is simpler for a pure CI gate.
No software install allowed
Browser winsOn a managed laptop where you can't apt install unzip or run an unsigned binary, the browser tool needs nothing but a tab. This is the single most common reason teams reach for it over the CLI.
You don't want to copy the file anywhere
Browser winsThe CLI requires the archive on the local disk; if your only copy is on a shared drive you'd otherwise stage it. JAD reads the file straight from the dropzone in your tab and never persists or transmits it — the verification leaves no copy behind.
Wrong password
Decryption failedAll three report a key failure distinct from corruption: unzip prints 'incorrect password', 7z reports a data error, and JAD returns a decryption-failure report rather than a CRC mismatch. A wrong password is never a CRC32 problem in any of them.
Reading the result programmatically
Browser winsParsing unzip -t output means scraping terminal text that varies by version and locale. JAD emits a stable JSON schema (totalEntries/passed/failed/results) that jq reads without brittle regex. For downstream tooling the structured output is easier.
Tamper detection rather than corruption
CRC32 insufficient — use SHA-256None of the three CRC32 checks proves a file wasn't deliberately altered — CRC32 is forgeable. For tamper detection use a cryptographic hash from checksum-generator (SHA-256) and compare manifests; that applies equally to the CLI tools, which also use CRC32.
Frequently asked questions
Is JAD's CRC32 check the same as `unzip -t`?
At the core, yes — both decompress every entry and compare its computed CRC32 to the value stored in the ZIP. The verdicts mean exactly the same thing. The differences are packaging: JAD needs no install, runs in a browser tab, and returns structured JSON; unzip -t returns terminal text and an exit code.
Can JAD test a 7z or rar like `7z t` does?
No. JAD's Archive Integrity Tester verifies ZIP CRC32 by parsing the ZIP central directory; a 7z or rar has no such directory and is rejected with Not a valid ZIP archive. For those formats, 7z t on the CLI is the equivalent. Confirm your file's real format with auto-format-detector first.
When is the browser tool genuinely better than the CLI?
When installing software is the friction (locked-down or shared machines), when you want a structured JSON artifact instead of scraping terminal output, when you'd rather not copy a sensitive file onto a shared box, or when a non-technical teammate needs to run the check without a terminal.
When should I prefer the CLI?
For archives larger than a couple of GB, for non-ZIP formats, and for CI/CD gates that key off an exit code. The CLI is disk-bound rather than memory-bound and pipes cleanly into shell scripts; JAD has no shell pipe and no public API.
Do any of these upload my archive?
No. unzip and 7z run locally, and JAD's tool runs as WebAssembly inside your browser tab — your archive is read from disk and never sent to a server. There is no server-side path for JAD's archive tools.
How big an archive can JAD verify compared to the CLI?
The CLI is limited only by disk. JAD caps at 50 MB on Free, 500 MB on Pro, and 2 GB on Pro-Media/Developer, with a separate per-archive entry-count limit (500 free, up to 500,000 on paid). Beyond 2 GB, use the CLI.
Do all three handle encrypted ZIPs?
Yes. JAD takes the password in its password field and decrypts via zip.js (AES-256 / ZipCrypto). unzip -P pass -t and 7z t -ppass do the equivalent. In every case the CRC32 is verified against the decrypted plaintext.
Why use a browser tool when I already know the CLI?
Mostly for the cases where the CLI is awkward: a machine without the package installed, a teammate who doesn't use a terminal, or a workflow that wants a JSON artifact attached to a review. If unzip -t is already in your muscle memory and the archive is local, keep using it.
Does a CRC32 pass in any of these tools prove the file is authentic?
No — CRC32 detects accidental corruption, not tampering, and it's forgeable. That's true of unzip -t, 7z t, and JAD alike. For authenticity, compute a SHA-256 with checksum-generator and compare against a trusted manifest.
Is there a JAD API I can script instead of the CLI?
There's no public HTTP API — archive tools are browser-only (apiAvailable: false). On Pro and above the @jadapps/runner can drive the tool in a headless browser for automation, but for a simple scripted CRC gate the CLI tools with their exit codes are usually the more direct fit.
What about TAR integrity, which neither CRC32-checks per file?
TAR stores only a per-header checksum, not a per-file CRC32, so neither JAD nor a plain CRC check verifies TAR contents the way they do ZIP. For a .tar.gz, the gzip layer has a single trailing CRC32 over the whole stream (gzip -t checks it); for stronger assurance compute a SHA-256 over the whole file with checksum-generator.
Will the verdicts ever disagree between JAD and the CLI on the same ZIP?
No — they read the same stored CRC32 from the same central directory and recompute it the same way, so a ZIP that passes unzip -t passes JAD's tester and vice versa. If they disagree, you're almost certainly testing two different copies of the file (e.g. one re-downloaded) or one tool decrypted with a different password. Compare the file's SHA-256 to confirm you're testing identical bytes.
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.