How to password tester in developer workflows
- Step 1
- Step 2Drop the artifact — Drag the single encrypted
.zip(release bundle, secrets pack, fixture). It reads ZIP only — not 7z/RAR. - Step 3Enter the expected password — Type the value your build/secrets system expects into the masked field. Only this exact string is tested.
- Step 4Run and read JSON — Get
{ filename, testedEntry, verdict }.correctmeans the artifact opens; the on-screen metrics show Verdict and Tested entry. - Step 5Mirror in CI — There is no archive HTTP API, so replicate the check in your pipeline:
unzip -P "$ZIP_PASS" -t artifact.zipand fail the job on a non-zero exit. Use this tool for the fast interactive pass. - Step 6Escalate corrupt artifacts — On an
error:verdict, run archive-integrity-tester or corrupted-zip-repair before blaming the password.
Developer scenarios for the tester
Common spots where a fast local ZIP password check beats a full extract.
| Scenario | Why verify, not extract | Verdict you want |
|---|---|---|
| Vendor SDK shipped as a locked ZIP | Avoid a multi-minute extract just to confirm the password works | correct before you wire it into the build |
| Encrypted secrets bundle at onboarding | Confirm the shared password without writing secrets to disk | correct before importing into your vault |
| Pre-upload release artifact | Catch a packaging typo before publishing | correct gate before gh release upload |
| Customer-mirror test fixture | Reproduce a locked export without slow extraction | correct so the fixture is usable in tests |
Output contract & CI mapping
The exact shape this tool emits and how to reproduce the check where a real CI pipeline (no HTTP API) is required.
| Field / verdict | Value | CI equivalent |
|---|---|---|
filename | The input archive's name | $ARTIFACT |
testedEntry | Name of the first encrypted entry, or null | First encrypted member listed by unzip -l |
verdict: correct | Password unlocks the first encrypted entry | unzip -P "$PW" -t "$ARTIFACT" exit 0 |
verdict: incorrect | Password/CRC mismatch | unzip 'incorrect password' / exit 82 → fail job |
verdict: error: <msg> | Non-password failure (corrupt/unsupported) | unzip read/format error → investigate, not retry |
no encrypted entries found in archive | Nothing encrypted to test | Artifact isn't password-protected — re-package |
Cookbook
Developer-flavored checks. JSON blocks are the literal tool output; shell blocks show the CI mirror you'd run in a pipeline (no archive HTTP API exists).
Gate a release upload on the right password
Confirm the artifact opens with the expected password before publishing it, so consumers don't download an un-openable bundle.
Artifact: my-sdk-1.4.0.zip (AES)
Password tried: "sdk-release-1.4.0"
Report:
{
"filename": "my-sdk-1.4.0.zip",
"testedEntry": "lib/core.wasm",
"verdict": "correct"
}
# safe to: gh release upload v1.4.0 my-sdk-1.4.0.zipVerify a secrets bundle without extracting it
An encrypted secrets pack arrives at onboarding. Confirm the shared password works before importing — without writing the secrets to disk.
Bundle: env-secrets.zip
Password tried: "OnboardKey#dev"
Report:
{
"filename": "env-secrets.zip",
"testedEntry": ".env.production",
"verdict": "correct"
}Catch a packaging typo locally
The CI step that zipped the artifact used the wrong password variable. The interactive check flags it before the slow pipeline does.
Artifact: build-output.zip
Password expected: "DeployPass2026"
Report:
{
"filename": "build-output.zip",
"testedEntry": "dist/app.js",
"verdict": "incorrect"
}
Fix the ZIP_PASS secret in CI and re-build.Mirror the check in a CI pipeline
There is no archive HTTP API, so the pipeline reproduces the same verification with unzip and fails the job on mismatch.
# .github/workflows/verify.yml step
- name: Verify artifact password
run: |
if unzip -P "$ZIP_PASS" -t artifact.zip > /dev/null; then
echo "verdict=correct"
else
echo "verdict=incorrect"; exit 1
fiFixture that isn't actually encrypted
A test fixture meant to mirror a locked export was zipped without encryption. The verdict makes the mistake obvious.
Fixture: locked-export.fixture.zip
Password tried: "fixture-pass"
Report:
{
"filename": "locked-export.fixture.zip",
"testedEntry": null,
"verdict": "no encrypted entries found in archive"
}
Re-create the fixture WITH encryption to match production.Edge cases and what actually happens
Looking for an HTTP API to call from CI
No APIArchive tools are browser/runner-side — there is no server endpoint to POST a ZIP to. For pipelines, mirror the check with unzip -P 'pass' -t and use this tool interactively.
Artifact is 7z or RAR
Unsupported formatIt reads ZIP only (zip.js). For 7z/RAR artifacts, verify with 7z t/unrar t. Prefer ZIP+AES for artifacts you want to check here.
Empty password
RejectedSubmitting nothing throws Enter a password to test. Wire your expected password into the field — it never tries a default.
Password with special characters
SupportedThe masked field takes the literal string, so $, backticks, and quotes need no escaping — unlike a shell -P argument that also lands in history.
Corrupt artifact, not wrong password
errorAn error: <msg> verdict means a non-password failure (corrupt/unsupported entry). Don't retry the password — run archive-integrity-tester.
Artifact exceeds tier limit
413 too largeFree tier caps at 50 MB / 500 entries. Large multi-module bundles may need Pro (500 MB / 50,000) or higher (up to 2 GB / 500,000).
Mixed encrypted + plaintext entries
ExpectedOnly the first encrypted entry is tested. A bundle where only some members are encrypted still verifies correctly against that first encrypted member.
Hoping to recover an artifact password
Not a recovery toolIt verifies a password you have; it does not brute-force. Store artifact passwords in your secrets manager — a lost AES password is not recoverable.
Verdict correct but extract fails in old unzip
Preservedcorrect means the entry decrypts under zip.js. An ancient unzip that lacks AES support may still fail — upgrade the CLI; the password is fine.
Reproducibility check after verify
PreservedVerifying is read-only and never rewrites the archive, so a build-output hash computed before and after the check is identical. Use checksum-generator to confirm.
Frequently asked questions
Is there an HTTP API I can call from CI?
No. Archive tools run browser/runner-side with no server endpoint. For pipelines, reproduce the check with unzip -P "$PW" -t artifact.zip and fail the job on a non-zero exit; use this tool as the fast interactive verifier.
What output does it produce?
JSON { filename, testedEntry, verdict }, downloadable as <name>-password-test.json. The metrics panel shows the Verdict and Tested entry name.
Can it verify 7z or RAR artifacts?
No. It reads ZIP only via zip.js. For 7z/RAR, use 7z t/unrar t. Prefer ZIP with AES for artifacts you intend to verify here.
Why verify instead of just extracting?
Extracting a large artifact to confirm a password takes minutes; this decrypts only the first encrypted entry and answers in milliseconds — ideal for a quick gate before upload or import.
Does it support AES?
Yes. AES and ZipCrypto entries are both handled; zip.js auto-detects the method. You only supply the password.
Does verifying modify the artifact?
No — it's read-only. Build hashes and reproducibility checks remain valid because the file is never rewritten.
Can I script it to brute-force?
No. It tests the single password you type. Wordlist/brute-force work is out of scope and should not be done on artifacts you don't own.
What does an 'error:' verdict mean?
A non-password failure — usually a corrupt or unsupported entry. Investigate with archive-integrity-tester rather than retrying the password.
Is the password safe to type here?
Yes — it stays in your browser; nothing is uploaded. Unlike a shell -P argument, it doesn't end up in shell history either.
How large an artifact can it check?
Free: 50 MB / 500 entries. Pro: 500 MB / 50,000 entries. Pro-media: 2 GB / 500,000 entries. Developer: 2 GB / 500,000 / unlimited files.
What if the artifact isn't actually encrypted?
You'll get no encrypted entries found in archive (testedEntry: null). That usually means the packaging step skipped encryption — re-package with a password.
How do I gate a release on this?
Run the interactive check before publishing, then enforce it in CI with unzip -P "$ZIP_PASS" -t artifact.zip so a wrong/missing password fails the release job.
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.