How to encryption detector vs 7z l, zipinfo, and unzip -v
- Step 1Compare on accuracy — All four read the same bytes, so verdicts agree. The detector and
7z l -sltboth name the AES strength (128/192/256);unzip -vonly hints 'encrypted';zipinfoshows the raw flag you must decode. For unambiguous ZipCrypto-vs-AES, prefer the detector or7z. - Step 2Compare on setup —
7z,zipinfo, andunziprequire installed packages and, on locked-down corporate machines, admin rights you may not have. The detector needs only a browser — useful when you can'tapt install p7zip-full. - Step 3Compare on output shape — CLI output is line-oriented text you scrape. The detector emits JSON: download it and gate a step with
jq -e '.encryptionSummary["ZipCrypto (legacy)"] == 0'instead of regexing a Method column. - Step 4Compare on privacy — Both paths are local. A CLI reads the file from disk; the detector reads it via the browser File API and never uploads. For untrusted ZIPs you don't want written to a build server, the browser path keeps the bytes in one ephemeral tab.
- Step 5Compare on format coverage —
7z llists 7z, RAR, and TAR too; the detector is ZIP-only. If you need to inspect a 7z's encryption, use7z. For ZIP — the format where ZipCrypto-vs-AES actually matters — the detector is the faster path. - Step 6Combine them — Use the detector for quick, shareable JSON verdicts; drop to
7z l -sltwhen you need full per-entry method/CRC/host-OS detail or are scripting in an existing shell pipeline.
Encryption detection: detector vs common CLI commands
All read the same plaintext flag and AES extra field, so verdicts match. The difference is clarity and setup.
| Capability | JAD detector | 7z l -slt | zipinfo | unzip -v |
|---|---|---|---|---|
| Names ZipCrypto vs AES-128/192/256 | Yes, per entry | Yes (Method column) | Flag only — decode yourself | Hints 'encrypted', not which |
| Per-entry breakdown | Yes (entries array) | Yes | Yes | Yes |
| Summary counts | Yes (encryptionSummary) | No (tally manually) | No | No |
| Needs install | No (browser) | p7zip / 7-Zip | Info-ZIP | Info-ZIP |
| Needs password | No | No (for listing) | No | No |
| Machine-readable out | JSON | Verbose text | Text | Text |
| Reads 7z / RAR / TAR | No (ZIP only) | Yes | No (ZIP only) | No (ZIP only) |
Which tool to reach for
The encryption signal is identical; pick by context.
| Situation | Best tool | Why |
|---|---|---|
| Locked-down laptop, no admin rights | JAD detector | No install needed; runs in the browser |
| Already scripting in bash with p7zip installed | 7z l -slt | Native to the pipeline; full per-entry detail |
| Want a shareable JSON verdict for a ticket | JAD detector | encryptionSummary pastes cleanly |
| Untrusted ZIP you don't want on the build server | JAD detector | Bytes stay in one browser tab |
| Need to inspect a 7z or RAR's encryption | 7z l -slt | Detector is ZIP-only |
| Quick yes/no 'is it encrypted at all' | zipinfo / unzip -v | Already installed on most Unix boxes |
Cookbook
Same archive, different tools. The detector's JSON and the CLI's text agree on the verdict because they read the same metadata.
ZipCrypto archive — detector vs 7z l -slt
A legacy-encrypted ZIP. 7z's Method column names ZipCrypto; the detector's JSON says the same thing in a summary you can gate on.
$ 7z l -slt vendor.zip | grep -E 'Path|Method'
Path = db.sql
Method = ZipCrypto Deflate
Path = keys.pem
Method = ZipCrypto Deflate
JAD detector (vendor-encryption.json):
"encryptionSummary": {
"AES-256": 0, "ZipCrypto (legacy)": 2, "Unencrypted": 0
}
Same verdict: both files are ZipCrypto.AES-256 archive — detector vs zipinfo
zipinfo shows an encryption flag but you'd have to know that an AES entry carries the 0x9901 extra field. The detector decodes the strength byte for you.
$ zipinfo secrets.zip
-rw---- 2.0 fat 2048 Bx u099 24-Jan-30 q3-report.pdf
... (the 'B' marks encrypted; strength not shown)
JAD detector:
{ "name": "q3-report.pdf", "encrypted": true, "method": "AES-256" }
The detector resolves the AES strength (256) that zipinfo leaves implicit.unzip -v is ambiguous about the method
unzip -v is great for CRC and compression but won't tell you ZipCrypto from AES. Use it to confirm 'encrypted', then the detector to confirm 'which'.
$ unzip -v archive.zip
Length Method Size Cmpr ... Name
10240 Defl:N 3120 70% ... report.pdf
(no column distinguishes ZipCrypto from AES)
JAD detector fills the gap:
{ "name": "report.pdf", "encrypted": true, "method": "ZipCrypto" }
→ re-encrypt with AES-256.Mixed-method archive surfaced in one report
Spotting a mixed archive on the CLI means tallying the Method column by hand. The detector's summary makes the split obvious at a glance.
$ 7z l -slt mixed.zip | grep Method | sort | uniq -c
2 Method = AES-256 Deflate
1 Method = ZipCrypto Deflate
JAD detector:
"encryptionSummary": {
"AES-256": 2, "ZipCrypto (legacy)": 1, "Unencrypted": 0
}
→ c.txt is the weak entry.CLI handles a 7z; detector does not
The detector is ZIP-only by design. For non-ZIP containers, the CLI is the right tool — the detector throws on them.
$ 7z l -slt backup.7z | grep -E 'Method|Encrypted' Method = LZMA2:24 7zAES:19 JAD detector on backup.7z: Error: Not a valid ZIP archive. → 7z encryption isn't classifiable by the ZIP detector; use 7z.
Edge cases and what actually happens
unzip -v can't name the encryption method
Tool limitationunzip -v lists compression method and CRC but has no column that distinguishes ZipCrypto from AES. It can confirm an entry is encrypted, not which scheme. Use it as a first pass, then the detector (or 7z l -slt) to resolve the actual method.
zipinfo flag must be decoded by hand
Manual stepzipinfo exposes the general-purpose flag but leaves you to know that AES entries carry the 0x9901 extra field and a strength byte. The detector decodes that to AES-128/192/256 automatically, removing the most error-prone manual step.
Verdicts disagree between tools
InvestigateBecause all tools read the same flag bit 0 and 0x9901 field, genuine disagreement is rare and usually means one tool was run on a different file (e.g. a re-encrypted copy) or the archive is corrupt. Re-run both on the exact same file; if the detector reports fewer entries, the central directory may be truncated.
CLI not installed / no admin rights
Blocked on CLIOn locked-down machines you may not be able to install p7zip or Info-ZIP. The detector needs only a browser, so it works where apt/brew/choco are unavailable — the main reason to prefer it over the CLI.
Input is a 7z, RAR, or TAR.GZ
Not a valid ZIP archiveThe detector parses the ZIP central directory only and throws Not a valid ZIP archive. on non-ZIP containers. 7z l -slt reads those formats and reports their encryption (e.g. 7zAES). For non-ZIP archives, the CLI wins; for ZIP, the detector is faster. Confirm format with auto-format-detector.
Scripting the verdict
SupportedScraping 7z l -slt's Method column with grep/awk is brittle. The detector's JSON is stable: download it and assert with jq -e '.encryptionSummary["ZipCrypto (legacy)"] == 0'. There's no server API for the detector, so the JSON-gate pattern is the scripting path.
Huge archive on the CLI vs browser
Memory bound7z l streams and handles very large archives comfortably. The detector reads the whole file into memory to scan the central directory, so multi-GB ZIPs press browser RAM and are capped at 2 GB even on paid tiers. For enormous archives, the CLI is the safer choice.
You only need a yes/no 'is it encrypted'
Overkill either wayFor a binary 'encrypted or not', unzip -v or zipinfo (already installed on most Unix systems) is fastest. Reach for the detector or 7z l -slt when you specifically need ZipCrypto-vs-AES and the strength.
Frequently asked questions
Will the detector and 7z give the same answer?
Yes, for ZIP archives. Both read the same plaintext metadata — flag bit 0 and the 0x9901 AES extra field — so the detector's method matches 7z l -slt's Method column (ZipCrypto vs AES-128/192/256). The detector additionally provides a summary count, which 7z makes you tally by hand.
Why can't unzip -v tell me ZipCrypto from AES?
unzip -v reports compression method and CRC, not the encryption scheme. It can show that an entry is encrypted but has no field distinguishing ZipCrypto from AES. The detector reads the AES extra field and strength byte to resolve the exact method.
Is the browser detector less accurate than a CLI?
No. Encryption type is plaintext metadata, and the detector parses the same central-directory bytes the CLI does. Accuracy is identical for ZIP; the difference is convenience (no install) and output (JSON vs scraped text).
Can the detector check a 7z or RAR like 7z l can?
No. The detector is ZIP-only and throws Not a valid ZIP archive. on other containers. 7z and RAR use different layouts (e.g. 7zAES), so for those you need 7z l -slt or the native tool. Confirm the format first with /archive-tools/auto-format-detector.
Do any of these tools need the archive password?
No — not the detector, zipinfo, unzip -v, or 7z l. Listing and encryption-type detection read plaintext metadata only. You'd only need the password to actually extract or to verify it, which is what /archive-tools/archive-password-tester does.
Which is better for a CI gate?
If you're already in a shell with p7zip, 7z l -slt | grep works but is brittle. The detector's JSON is more robust: run it, download the report, and assert with jq. There's no server API for the detector, so the JSON-gate is the supported automation path; for a fully scripted in-pipeline check on a build server, the CLI is more direct.
Is the browser path actually private?
Yes. The detector reads the file in the tab via file.arrayBuffer() and never uploads it — equivalent to running a local CLI, but with nothing installed. For untrusted ZIPs you don't want written to a shared build server, the browser tab is the tighter boundary.
What about very large archives?
CLIs stream and handle multi-GB files comfortably. The detector loads the whole file into memory and is capped at 2 GB even on paid tiers, so for enormous archives prefer 7z l. For typical shared ZIPs, the detector is faster end-to-end.
How do I read a zipinfo flag manually if I want to?
The leading attribute string's encryption marker tells you an entry is encrypted, but distinguishing AES requires inspecting the 0x9901 extra field and its strength byte — exactly the decoding the detector automates. If you want the raw bytes, /archive-tools/archive-metadata-extractor exposes per-entry extra-field details.
Do the tools agree on entry counts?
They should, on an intact archive. If the detector reports fewer entries than 7z l, the central directory may be truncated — the detector stops at the first bad central-directory signature. Run /archive-tools/corrupted-zip-repair to assess damage.
Can I use the detector offline like a CLI?
Yes. Once the page loads, detection is pure client-side ZIP parsing with no network calls, so it runs on air-gapped machines — one of the few cases where a 'web' tool matches a CLI for offline use.
Should I replace my CLI workflow with the detector?
Not necessarily. Keep the CLI for non-ZIP formats, huge archives, and existing shell pipelines. Use the detector for quick ZIP checks on locked-down machines, shareable JSON verdicts, and untrusted files you'd rather not write to disk. Many people use both.
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.