How to troubleshooting the password tester
- Step 1Read the exact verdict — Open the result and note the Verdict and Tested entry. The verdict string tells you the failure class; the entry name tells you what was actually checked.
- Step 2If 'incorrect', sanitize the password — Retype rather than paste, or paste then delete trailing whitespace. Watch for smart-quotes (
'vs'), and confirm case — ZIP passwords are byte-exact. - Step 3If 'error:', suspect corruption — A non-password failure means the entry may be damaged. Run archive-integrity-tester; if it confirms damage, try corrupted-zip-repair.
- Step 4If 'no encrypted entries', confirm encryption — The ZIP has no encrypted entries to test. Verify with encrypted-archive-detector — the archive may simply not be password-protected.
- Step 5If nothing loads, check the format — 7z and RAR aren't supported (zip.js is ZIP-only). Confirm the file is a real
.zip, not a renamed 7z/RAR. - Step 6If rejected before processing, check tier limits — Files over 50 MB or 500 entries are rejected on the free tier. Upgrade for 500 MB / 50,000 (Pro) up to 2 GB / 500,000 (Pro-media/Developer).
Verdict-by-verdict diagnostics
Every verdict the tool can emit, the likely cause, and the fix. Verdict strings are exactly what the processor returns.
| Verdict / symptom | Likely cause | Fix |
|---|---|---|
incorrect (but I'm sure it's right) | Trailing space, smart-quote, or wrong case in the password | Retype or paste-then-trim; check quote characters and case |
error: <message> | Decryption failed for a non-password reason — usually corruption | Run archive-integrity-tester; repair with corrupted-zip-repair |
no encrypted entries found in archive | The ZIP has no encrypted entries | It isn't password-protected — confirm with encrypted-archive-detector |
Enter a password to test. | Password field was empty | Type the candidate password before running |
| Nothing loads / can't read file | File is 7z, RAR, or a renamed non-ZIP | Use a real .zip; 7z/RAR aren't supported by this tool |
| Rejected before processing | File over the tier file-size or entry-count cap | Reduce size or upgrade tier (see limits below) |
Tier limits that cause rejections
A ZIP over these caps is rejected before any password is tested. The whole central directory is read, so the entry-count cap applies too.
| Tier | Max file size | Max entries | Files per run |
|---|---|---|---|
| Free | 50 MB | 500 | 1 |
| Pro | 500 MB | 50,000 | 20 |
| Pro-media | 2 GB | 500,000 | 100 |
| Developer | 2 GB | 500,000 | Unlimited |
Cookbook
Worked diagnostics for the verdicts people report most. JSON blocks are the literal tool output; the notes explain the fix.
'incorrect' caused by a trailing space
The password was copied from a chat message that included a trailing space. ZIP passwords are byte-exact, so the space makes it wrong.
Pasted password: "Summer2026 " <- trailing space
Report: { "verdict": "incorrect", "testedEntry": "notes.txt" }
After trimming to "Summer2026":
Report: { "verdict": "correct", "testedEntry": "notes.txt" }'incorrect' caused by smart-quotes
A password containing an apostrophe was autocorrected to a curly quote when typed in a document, so it no longer matches.
Typed: "don’t-tell" (curly ’)
Report: { "verdict": "incorrect" }
Typed: "don't-tell" (straight ')
Report: { "verdict": "correct" }'error:' means corruption, not wrong password
Retyping the password keeps failing with an error verdict. That's a corruption signal — escalate to integrity/repair instead.
Report: { "verdict": "error: invalid distance too far back", "testedEntry": "data.bin" }
Next step: archive-integrity-tester -> confirms damage
corrupted-zip-repair -> attempts a fix
(Do NOT keep retyping the password.)'no encrypted entries' — it isn't encrypted
The archive was never password-protected, so there's nothing to test regardless of what you type.
Report:
{
"filename": "shared.zip",
"testedEntry": null,
"verdict": "no encrypted entries found in archive"
}
This ZIP has no password. Confirm with encrypted-archive-detector.Dropped a 7z by mistake
A .7z (or a 7z renamed to .zip) can't be read — the tool decrypts ZIP only.
Input: backup.7z (or backup.zip that is really 7z) Result: the ZIP reader can't parse it; no verdict is produced. Fix: this tool supports ZIP only. Use a 7z-capable tool for 7z/RAR.
Edge cases and what actually happens
Sure the password is right but get 'incorrect'
incorrectAlmost always a trailing space, a smart-quote, or a case difference — ZIP passwords are byte-exact. Paste then trim, and check quote characters before assuming a tool bug.
'error:' verdict won't go away
errorThis is a non-password failure (usually corruption). Retyping the password won't help. Run archive-integrity-tester and, if damaged, corrupted-zip-repair.
'no encrypted entries found in archive'
By designThe ZIP has no encrypted entries, so there is nothing to test (testedEntry: null). It simply isn't password-protected — confirm with encrypted-archive-detector.
Empty password submitted
RejectedThe tool throws Enter a password to test. Type a candidate first — it won't try a blank or default password.
7z or RAR file
Unsupported formatOnly ZIP is supported (zip.js). 7z and RAR — including a 7z renamed to .zip — can't be parsed and produce no verdict. Use a native 7z/RAR tool.
File rejected before testing
413 too largeFiles over the tier cap (Free 50 MB / 500 entries) never reach the password step. Reduce size or upgrade — Pro 500 MB / 50,000, Pro-media/Developer 2 GB / 500,000.
Huge archive feels slow to start
ExpectedThe whole central directory must be read to find the first encrypted entry, so a 100,000-entry ZIP takes a moment to open even though decryption itself is tiny.
Only some entries are encrypted
ExpectedThe tool tests the first encrypted entry. If you expected a different entry, note that mixed archives are tested against the first encrypted member, not a specific file you choose.
Correct verdict but another tool still won't open it
Preservedcorrect means the first encrypted entry decrypts under zip.js. If a legacy unzip fails, it likely lacks AES support — upgrade that tool; the password is right.
Expecting it to recover a forgotten password
Not supportedIt verifies a password you supply; it does not brute-force or recover. A lost AES password is not feasibly recoverable — restore from backup.
Frequently asked questions
It says 'incorrect' but I know the password — why?
Check for a trailing space, a curly/smart-quote substituted for a straight quote, or a case difference. ZIP passwords are byte-exact, so any of these makes it wrong. Paste then trim and re-check.
What does an 'error:' verdict mean?
Decryption failed for a reason other than a wrong password — usually corruption. Don't keep retyping; run archive-integrity-tester and, if damaged, corrupted-zip-repair.
What does 'no encrypted entries found in archive' mean?
The ZIP has no encrypted entries, so there's nothing to test (testedEntry is null). It isn't password-protected. Confirm with encrypted-archive-detector.
Why won't my 7z or RAR file work?
This tool decrypts ZIP only (via zip.js). It cannot read or test passwords on 7z or RAR archives. Use a native 7z/RAR utility for those.
I left the password blank and got an error.
That's expected — the tool throws Enter a password to test. It never tries a blank or default password; type a candidate first.
My file was rejected before it even tested.
It exceeded your tier's limit. Free allows 50 MB / 500 entries; Pro 500 MB / 50,000; Pro-media/Developer 2 GB / 500,000. Reduce the file or upgrade.
Why is it slow to start on a big archive?
It reads the full central directory to locate the first encrypted entry. A ZIP with tens of thousands of entries takes a moment to open, even though the actual decryption is tiny.
Can it recover a forgotten password?
No. It only verifies a password you supply — no brute-force, no recovery. A lost AES password cannot be feasibly recovered; restore from a backup.
Does it support AES, or only ZipCrypto?
Both. zip.js auto-detects each entry's encryption method, so AES and legacy ZipCrypto entries are handled the same way — you just provide the password.
It says correct but my unzip still fails.
A correct verdict means the first encrypted entry decrypts under zip.js. An old unzip that lacks AES support may still fail; upgrade that CLI — the password itself is fine.
Which entry does it actually test?
The first encrypted, non-directory entry it finds. The result's Tested entry field shows which one. Plaintext entries and folders are skipped.
Is my password or file sent anywhere when something fails?
No. Everything runs in your browser — both the file and the password stay local even when a verdict is incorrect or error:. Nothing is uploaded.
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.