Offline recovery removes some dependencies, not every risk
An inheritance plan may be needed years after it was created. By then, an account may be inaccessible, a domain may have changed, or the original provider may no longer operate.
A saved offline decryptor can reduce that dependency. But it is not a promise that one HTML file will work unchanged forever. The recipient still needs a compatible browser, intact files, the correct recovery inputs, and trustworthy instructions.
What the PingVaults decryptor contains
The PingVaults decryptor is a standalone HTML file containing the interface and decryption logic. It uses the browser's Web Crypto API to perform PBKDF2 key derivation and AES-GCM decryption. The Web Cryptography API is standardized by the W3C, but browser support and platform behavior should still be tested periodically.
The decryptor file does not contain your vault plaintext, recovery phrase, or derived key. Those are supplied only during recovery.
Two distinct recovery modes
Saved-copy recovery: fully offline
The strongest provider-independent path uses two files saved in advance:
- the PingVaults offline decryptor;
- an exported metadata JSON that includes the ciphertext, salt, IV, recovery-field structure, language setting, and transaction identifier.
Open the saved HTML while disconnected from the network, paste or import the metadata, enter the recovery values, and decrypt locally. In this mode, no gateway or PingVaults account is required.
TxID retrieval: network required
The decryptor can also request ciphertext from an Arweave or Irys gateway using a transaction ID. That convenience requires a network connection and contacts the selected gateway. The recovery values and resulting plaintext are still processed locally, but the gateway can observe the request for that transaction.
This distinction matters: a tool is not operating fully offline while it is fetching data from a gateway.
What happens during decryption
- The recipient imports the exported metadata or enters the ciphertext and parameters.
- The interface displays the stored recovery-field order and prompt text.
- The recipient enters the values locally. The high-entropy recovery phrase—not personal facts—should provide the primary protection.
- The browser derives a key with the recorded salt and parameters.
- AES-GCM either authenticates and decrypts the payload or fails without revealing partial plaintext.
The decrypted content exists in the browser process and on the screen. It can still be exposed by malware, screen recording, browser extensions, clipboard history, or an untrusted device. "Local" does not mean "immune to compromise."
A practical recovery package
Use the digital asset inventory template to label the package and the family recovery-drill checklist to test discovery, file access, and stop decisions as well as decryption.
Keep the following together only when the resulting access risk is acceptable:
- a tested copy of the decryptor;
- the exported metadata JSON;
- a short, plain-language instruction sheet;
- the release/version date and a file hash;
- a separate route to the recovery phrase.
The metadata contains ciphertext and public decryption parameters. It should not contain the recovery phrase, but it is still sensitive operational material because it gives an attacker everything needed to perform offline guesses.
Verify before trusting it
Test with harmless content
Create a test vault, export its metadata, disconnect the network, and recover it with the saved decryptor. Repeat on the browser and operating system the recipient is likely to use.
Inspect network behavior
With browser developer tools open, import the ciphertext rather than using TxID retrieval. Confirm there are no network requests during the saved-copy recovery path.
Verify file integrity
Compare the decryptor hash with the value shown on PingVaults' verification page or the published source release. A saved file can be replaced or modified like any other local file.
Re-test after changes
Run the drill again after changing the recovery phrase, vault format, contacts, device, browser, or decryptor version. Keep the working version rather than assuming a future download will be available.
Limitations to plan around
- Long-term browser compatibility cannot be guaranteed.
- A damaged or lost decryptor and metadata package cannot recover itself.
- A weak recovery phrase remains vulnerable to offline guessing.
- An infected recovery device can capture inputs and plaintext.
- The decryptor provides technical access, not legal authority.
For high-value assets, keep redundant verified copies in separate locations and involve appropriate legal and security professionals.
Bottom line
An offline decryptor is valuable because it gives recipients a recovery path that can work from saved files without a provider account or network connection. Its real benefit is reduced dependency and inspectability—not magic permanence.
Download and test the PingVaults offline decryptor →