Your archive stays on your device

The data flow

When you select a file, the browser reads its bytes with the File API. The page parses the ZIP structure on your device, picks one encrypted entry, preferring the smallest one large enough to confirm a password decisively, and gives each Web Worker only the bytes it needs to test passwords (for AES, the salt, verification value, ciphertext, and authentication code; for ZipCrypto, that entry's encrypted bytes), along with a summary of the archive (entry names and sizes). The workers run the password checks, with the heavy hashing in WebAssembly (hash-wasm) or, for AES key derivation, the browser's built-in Web Crypto when that is faster on your device, and they never hold the whole archive. Nothing in this flow goes to a server, and it looks like this:

Your ZIP file
  --> Browser File API (local)
  --> ZIP parsed on the page (local)
  --> Web Workers test passwords (local)
  --> Result shown only to you

There is deliberately no branch in that diagram that sends your archive to a server. The recovery engine contains no network code that sends file data. This is the heart of whether online ZIP password tools are safe: the risk lives in the upload, and your archive is never uploaded here.

Two things the tool keeps on your device stay in this browser: a short-lived copy of a file handed off from the home page (in local IndexedDB, deleted as soon as the recovery page reads it) and, during a paused mask or brute-force search, a resume record in local storage. Neither is ever sent to us. Section 4 of the privacy policy lists exactly what each holds and how to clear it, which matters on a shared computer.

Error reports and analytics

If the site's own code fails in your browser, it posts a short report to /api/error on this site, and the site's server logs it (it is set up to forward reports to our central error hub, which is not running yet). The report holds the error type and message, the stack trace, the address of the script with its line and column, the page path (no query string), the page language, your browser's user agent, the time, the site's release, and, for a failure inside the recovery tool, a one-word label for the part that failed. It never includes your archive, its contents or file names, or any password, and the browser sends at most ten reports per page view. Reports are kept for up to 90 days (see section 4 of the privacy policy).

The recovery tool includes an analytics hook in its own code. It can record only a few non-identifying labels about a run (the encryption scheme, the archive's AES key size where it has one, the mode you chose, and whether the archive is supported), and never your archive, its contents or file names, or any password. No collector is attached today, so it sends nothing. Cloudflare still records standard request metadata for each page view (see section 4 of the privacy policy). Any future aggregate site analytics will stay within that same allowlist and will never receive archive contents, filenames, candidate passwords, recovered passwords, or archive hashes.

Untrusted-input security model

A ZIP archive you load could be malformed or hostile, so the engine treats every file as untrusted:

• Bounds-checked parsing. The format parser validates every offset and length before reading, so a truncated or crafted archive raises a clean error instead of reading out of bounds.
• Memory limits. The tool tests passwords against a single encrypted entry of at most 256 MB compressed, and decompressing it stops as soon as the output passes the size the archive declares for that entry, so a decompression-bomb style entry cannot expand without limit. The archive you load is read into memory whole.
• Verification without extraction. Testing a password does not require extracting arbitrary files. Confirmation reads only the one verification entry (the smallest entry that gives a definitive check, when the archive has one): for AES it checks the stored HMAC over the encrypted data, and for ZipCrypto it decrypts the entry, inflates it if it is Deflate-compressed, and matches its CRC-32.
• No code execution. Archive contents are treated purely as data. Nothing inside an archive is ever executed or interpreted.

Open-source components

Recovery is built on established, licensed open-source libraries. The key derivation, HMAC and CRC-32 come from hash-wasm or the browser's Web Crypto; the ZipCrypto keystream follows PKWARE's published specification in our own code, which the tests check against archives zip.js writes.

Transport and headers

The site is served over HTTPS with a strict Content-Security-Policy, X-Content-Type-Options: nosniff, a restrictive Permissions-Policy, and frame-ancestors 'none' to prevent clickjacking. WebAssembly is permitted via script-src 'wasm-unsafe-eval'; connections are limited to the site's own origin.

Limitations, honestly

Because recovery is client-side, we cannot see or control how the tool is used, which is why authorized-use is a policy you accept rather than something we can technically enforce. And no tool can recover an arbitrary strong password: AES archives in particular use slow key derivation that makes guessing expensive by design.