How to encrypted zip in developer workflows
- Step 1Collect the files to share — Gather the secrets/artifacts locally — e.g.
.env.production,tls/server.key,tls/server.crt. Keep them in their intended folder layout so the preserved paths reconstruct correctly. - Step 2Open the tool on Pro — Go to /archive-tools/encrypted-zip-creator (this is
minTier: pro). Drop the files into 'Drop files to process' — any file type is accepted and it is multi-file. - Step 3Set a strong, shareable password — Type a 12+ character passphrase (8 is the hard floor). For a handoff, generate it in a shared vault item the recipient can read — never send the password down the same channel as the file.
- Step 4Generate the bundle — Click Generate. zip.js writes each file as an AES-256 entry and produces
encrypted.zip. The metrics panel showsFiles,Encryption: AES-256, andSaved— note there is no level slider to tune here. - Step 5Attest with a checksum (optional but recommended) — Run the downloaded ZIP through checksum-generator. Drop the SHA-256 into the PR description, ticket, or vault item so the recipient can confirm the bundle is the one you built.
- Step 6For reproducibility, normalise timestamps first — If you need byte-stable bundles across machines, run the inputs (or a pre-built ZIP) through timestamp-normalizer with a fixed date before encrypting — the Encrypted ZIP Creator itself does not pin timestamps.
Developer scenarios mapped to the tool
What the Encrypted ZIP Creator does for each pattern, and the honest limits. Grounded in createEncryptedZip and the options panel.
| Scenario | How this tool helps | Pair / caveat |
|---|---|---|
Ship .env + keys to a teammate | One AES-256 ZIP, paths preserved, password out-of-band | Put the password in a shared vault, not chat |
| Lock a build artifact for a contractor | Encrypt the dist bundle so only the holder of the password opens it | Attest with checksum-generator |
| Attach a sensitive log bundle to a ticket | Encrypted before it lands on the tracker | Filenames stay visible — use a generic inner name if needed |
| Reproducible encrypted bundle | Standard ZIP byte stream you can hash | Normalise dates first via timestamp-normalizer |
| Tune compression for a large artifact | Not supported here — no level control, handler ignores it | Use smart-archive-compressor (no encryption) |
Options: what's real vs assumed
Engineers often assume controls that aren't there. This is what the encrypted-zip-creator option panel actually exposes.
| Assumed control | Present? | Reality |
|---|---|---|
| Password field | Yes | Single type=password input; min 8 chars enforced |
| AES key-size selector (128/192/256) | No | Hardcoded to AES-256 (encryptionStrength: 3) |
| Compression-level slider | No | Not rendered; createEncryptedZip ignores compressionLevel |
| Output filename | No | Always encrypted.zip; rename after download |
| Folder picker | No | Multi-file drop only; folder pickers are folder-to-zip / selective-zipper |
| Timestamp pinning | No | Use timestamp-normalizer for reproducible dates |
Cookbook
Patterns from real dev handoffs. Never put the password in the same place as the file or in a script.
Encrypt local-dev secrets for a new teammate
The classic onboarding handoff: env file plus TLS material, structure preserved so it drops straight into their checkout.
Files (paths preserved): .env.development certs/localhost.key certs/localhost.crt Password: from shared 1Password item 'dev-onboarding' Generate → encrypted.zip Teammate: unzip -P <pw> encrypted.zip → .env + certs/ in place
Lock a build artifact for a contractor
Hand off a dist bundle without giving repo access, and attest it so the contractor knows it's untampered.
Drop: dist/ (built locally, 78 files) Password: vault-generated 24-char Generate → encrypted.zip (Files: 78 Encryption: AES-256) Attest: checksum-generator → SHA-256 = 4c9e...a712 paste into the statement-of-work / ticket Contractor verifies hash, then opens with the password.
Reproducible encrypted bundle
The Encrypted ZIP Creator does not pin timestamps. To get a stable hash across machines, normalise dates first, then encrypt.
Step 1: timestamp-normalizer on a pre-built source.zip
target date 1980-01-01
Step 2: extract, drop the files into encrypted-zip-creator
same password → encrypted.zip
Result: content bytes stable across machines (note: zip.js
may still vary container metadata — verify with a hash diff).Don't reach for a compression level — it isn't here
If your goal is the smallest possible artifact with a tuned level, this tool can't do it; route through the right sibling.
Want: maximum compression on a 400 MB artifact Encrypted ZIP Creator: no level slider; handler ignores compressionLevel → deflate runs at zip.js default. Do instead: smart-archive-compressor (level 0-9) → compress then encrypted-zip-creator → encrypt the result (note the second pass won't shrink the already-compressed ZIP)
Encrypted log bundle on a ticket
Attach diagnostics to a shared tracker without leaving them in plaintext; mind that filenames remain visible.
Drop: app.log, query-trace.json, env-redacted.txt Password: out-of-band to the assignee Generate → encrypted.zip → attach to ticket Note: 'app.log' etc. are listable without the password. If the names leak context, wrap into bundle.zip first, then encrypt the single bundle.zip.
Edge cases and what actually happens
No compression-level option
Not presentThe options panel for this tool renders only a password field, and createEncryptedZip never reads compressionLevel — deflate uses the zip.js default. If you need level control, compress first with smart-archive-compressor (which exposes a 0-9 slider but applies no encryption), then encrypt the result.
Not a drop-in reproducible-build step
CaveatZIP records modification times, and this tool does not pin them. Two encrypts of the 'same' tree from different machines can differ. For reproducibility, normalise dates with timestamp-normalizer first; even then, container metadata from zip.js should be confirmed with a hash diff rather than assumed identical.
No programmatic API on the page
UI-drivenThe page is interactive — there is no public REST endpoint to POST files to for this tool. Paid tiers can route a job to the local @jadapps/runner (headless Chromium running the same zip.js engine), but for scripted CI encryption the practical equivalent is 7z a -tzip -mem=AES256 on the command line.
Password under 8 characters
RejectedcreateEncryptedZip throws 'Choose a password of at least 8 characters (12+ recommended).' For handoffs, generate a 16-24 char passphrase in a vault so the floor never blocks you and the secret is strong.
Filenames leak context in a shared tracker
By designAE-2 encrypts contents, not entry names — prod-db-creds.env is listable from the attached ZIP without the password. If the names themselves reveal sensitive context, wrap everything into one inner bundle.zip under a neutral name, then encrypt that single file.
Re-encrypting an already-compressed artifact shows ~0% saved
ExpectedEncrypting an existing .zip, .jar, or media file yields a near-0% Saved figure because the input has no compression headroom and AES output is incompressible. This is normal; the encryption still applied.
Free-tier developer account
Blocked (upgrade)The tool is minTier: pro; free or signed-out sessions get a plan overlay instead of the dropzone. A Pro plan is required to encrypt; Pro+Media/Developer raise the per-file ceiling to 2 GB for large artifacts.
Output always named encrypted.zip
Rename on saveEvery run downloads encrypted.zip. For a PR or ticket, rename to something meaningful (e.g. onboarding-2026-06-13.zip) right after download so the attachment is self-describing.
Frequently asked questions
Is there a CLI or API equivalent I can script?
The page is interactive; there is no public REST endpoint for this tool. Paid tiers can route jobs to the local @jadapps/runner (headless Chromium, same zip.js engine), but for unattended CI encryption the practical equivalent is 7z a -tzip -mem=AES256 -p out.zip ./files, which produces the same AE-2 AES-256 format.
Can I set the compression level?
No. The Encrypted ZIP Creator's options panel only shows a password field, and the handler ignores compressionLevel — deflate runs at the zip.js default. Use smart-archive-compressor for a 0-9 level slider, then encrypt the output here.
How do I make the output reproducible?
This tool doesn't pin timestamps, so it isn't reproducible on its own. Run your files (or a pre-built ZIP) through timestamp-normalizer with a fixed date first, then encrypt. Confirm stability with a hash diff via checksum-generator rather than assuming it.
Is it safe to send secrets this way?
AES-256 (AE-2) is strong, but the security depends on the password. Send the password out-of-band (a shared vault item), never in the same email/chat as the file, and use 12+ characters. Filenames remain visible, so avoid embedding secrets in entry names.
Will the recipient need JAD to open it?
No. It's a standard AES-256 ZIP — unzip -P, 7-Zip, Keka, or WinZip open it with the password. There is no JAD wrapper, so the handoff doesn't depend on JAD being reachable.
Can I bundle a whole folder of config?
Yes — drop the files and their relative paths are preserved as entry names, so the folder tree rebuilds on extraction. It is multi-file but not a one-click folder picker; for that use folder-to-zip, which however produces an UNENCRYPTED ZIP.
How do I attest the bundle in a PR?
Run the downloaded encrypted.zip through checksum-generator and paste the SHA-256 into the PR/ticket. The reviewer re-hashes the file they received and compares — proving it's the exact bundle you built.
Can I script bulk encrypted runs?
By tier, a single job takes up to 20 files (Pro) / 100 (Pro+Media) / unlimited (Developer), but each run is one interactive Generate. For high-volume archive processing in general, see batch-compression-report; for true unattended encryption, use the 7z CLI.
Can I choose AES-128 for speed?
No — strength is hardcoded to AES-256 (encryptionStrength: 3) and the UI states it's fixed at maximum. The speed difference is negligible for typical artifact sizes, and removing the choice prevents shipping weaker crypto by mistake.
Does the output work with my CI's format expectations?
It's a standard .zip with AES entries — any consumer that handles AES-256 ZIP reads it. There's no JAD-specific format. Note CI steps that need to *read* the contents will need the password and an AES-aware unzip in the runner image.
What's the largest artifact I can encrypt?
Per file: Pro 500 MB, Pro+Media 2 GB, Developer 2 GB; entries up to 500,000 on higher tiers. For artifacts above 2 GB, the 7z CLI (streaming) is the better path; zip.js buffers the result Blob in memory.
Can I verify the password before sending?
Yes — run archive-password-tester with the password to confirm the AES entries decrypt, and encrypted-archive-detector to confirm the ZIP is actually encrypted, both before you hand it off.
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.