Online password recovery has usually meant handing your file to a remote server and trusting it. Browser-based recovery flips that around: the archive never leaves your device, and the cryptographic work happens locally through WebAssembly. This post explains how that is possible and why it is a meaningful privacy improvement.

The old model: upload and hope

Classic online recovery tools ask you to upload the archive to a server that does the work. The trouble is that a ZIP you have lost access to is often exactly the kind of file you would least like to hand over, such as financial records, backups, or personal documents.

Once uploaded, that file lives on someone else’s disk. It may be logged, cached, or retained, and you have no way to verify what actually happens to it. Even when the service means well, uploading sensitive data simply widens the number of places it can leak from.

The local-first model

Modern browsers can do everything recovery needs without a server in the loop:

  • The File API reads the archive’s bytes directly from your disk into the page’s memory when you select the file. Those bytes stay in the browser tab.
  • WebAssembly runs the heavy cryptography, including PBKDF2, HMAC, and CRC, fast enough to test passwords locally. For AES key derivation, the tool also times the browser’s built-in Web Crypto and uses it instead when it is faster on your device.
  • A pool of Web Workers, one per CPU core, runs the search on background threads, so the interface stays responsive. Mask and brute-force candidates are generated inside the workers; a dictionary you type or load is handed to them from the page. None of them is sent over the network.

Nothing in that pipeline requires sending your file anywhere.

Why WebAssembly matters here

Verifying an AES password is dominated by PBKDF2-HMAC-SHA1 with 1000 iterations, computed once per guess. That is a tight numerical loop, exactly the kind of work that plain JavaScript does relatively slowly and that compiled WebAssembly does quickly. Running the hot path in WebAssembly, or in the browser’s native Web Crypto, rather than in plain JavaScript is what makes local recovery practical rather than painfully slow. It does not change the underlying math, but it lets your own hardware test far more candidates per second.

What actually happens, step by step

  1. You choose a file. The browser reads it locally, and the file is not sent anywhere.
  2. The page parses the archive’s structure to find its entries, detect the encryption scheme, and pick an entry for the workers to test, preferring the smallest encrypted entry large enough to confirm a password decisively (among entries up to 256 MB compressed).
  3. Mask and brute-force candidates are generated inside the workers; a wordlist (yours and, if enabled, the built-in list of common passwords) is passed to them from the page, and the workers add any variations you enabled.
  4. Each candidate is verified with the cheap filter first, then a confirmation check for any survivor.
  5. When a password confirms, it is displayed to you, on your screen only.

At no point is the archive, a candidate, or the final password transmitted. The confirmation step recomputes the HMAC for AES and decrypts and checks the CRC-32 for a ZipCrypto entry of at least 4 bytes that is stored or Deflate-compressed, so on an AES archive a wrong password is effectively never reported, and on nearly every ZipCrypto one a reported password has passed a check that a wrong password clears about once in 2^40 candidates: very rarely, but not never on a very long search. When only a shorter ZipCrypto entry can be tested, the result says the password passed only a quick check. How it works explains the rare exception and gives the full picture.

Why local processing is genuinely more private

  • The file never leaves your device, so there is no upload to intercept, store, or leak.
  • Passwords under test are not logged or transmitted; each candidate is tested in a worker and then discarded.
  • There are no server-side records of your file names or contents, because there is no server handling them.

This is the core of our security approach: the most private way to handle a sensitive file is not to move it at all.

What the tool keeps, and for how long

Because recovery runs inside the page, its footprint is small. The archive’s bytes live in the tab while it is open, each candidate is tested in a worker and then discarded, and the progress and time estimates come from your own testing rate. Two things can outlast the tab, both on your device only. A ZIP you drop or choose on the home page waits in the browser’s storage until the recovery page opens and deletes it, so it outlasts the tab only if the recovery page never opens. And a running mask or brute-force search saves its settings (including the file’s name and size and any mask you typed) and its progress, so you can resume after a reload or after closing the tab; that record is deleted when the search finishes, when you press Stop, or when you choose Start fresh. Neither is ever sent anywhere; the privacy policy lists what they contain and how to clear them. There is no account and no server-side history of your recoveries.

The honest limits

Local-first is a privacy win, not a magic wand:

  • Speed depends on your own hardware. A laptop tests fewer AES candidates per second than a large machine would, so a strong password remains out of reach, which is the whole point of encryption.
  • Recovery still depends on narrowing the search. Local processing changes where the work happens, not the mathematics of guessing.

None of that changes the recommendation, because a strong password being hard to guess is precisely what protects your data. When you want to try, everything runs on the recovery page.

Verify the privacy claim yourself

You do not have to take anyone’s word for it:

  • Open your browser’s developer tools, switch to the Network tab, then load a file and start a short recovery. You will see the page download its own scripts, including the worker and the WebAssembly probe, and nothing that carries your archive. The only request that sends data is a POST to /api/error, and only if the site’s own code hits an error; it carries the error message and stack trace, the page path, and your browser’s user agent (section 4 of the privacy policy lists every field), never file data or passwords.
  • For a second check, keep the Network tab open while that search runs: you will see no request to another site and no upload of your archive. The requests you do see go to this site, such as the script each worker loads, and none carries your file or a password.

As always, run recovery only on archives you own or are authorized to open.

In short

  • Browser-based recovery reads your file locally with the File API and never uploads it.
  • WebAssembly makes the slow AES key derivation fast enough to run on your own device.
  • Web Workers keep the interface responsive, and no candidate goes over the network.
  • You can check for yourself that your file never leaves your machine.