Before relying on an encrypted file, prove that you can decrypt a saved copy and recover the original bytes. Encryption success in a browser tab is only the first step. A lost password, an unsaved download or an unreadable format can make otherwise sound cryptography useless to the person who needs the file later.
Start with a disposable sample, keep the original and complete a round trip. Then decide where the encrypted copy, password and recovery instructions will live. The storage plan matters as much as the button that performs encryption.
Understand this tool's format
The browser file vault uses a documented tool-specific format identified as FPSVAULT1. It derives a key from the passphrase with PBKDF2-SHA-256 at 600,000 iterations, using a fresh 16-byte salt. File encryption uses AES-256-GCM with a fresh 12-byte IV and a 128-bit authentication tag.
The format authenticates its header and encrypts original filename metadata. This helps detect altered ciphertext or incompatible data when decryption is attempted. It is not a widely interchangeable archive standard, and the project does not claim an independent cryptographic audit or certification.
Keep access to a compatible decryptor and the format documentation. A file extension alone does not guarantee that another encryption application can open it. If long-term interoperability is a requirement, choose a format and maintenance plan suited to that requirement before moving important archives.
Choose a passphrase you can retain securely
The interface requires a minimum passphrase length for encryption and asks for confirmation. Length validation catches some input mistakes, but it does not prove the passphrase is unpredictable. Use a password manager or another suitable random generation method rather than a familiar quotation or reused account password.
PBKDF2 increases the work required to test password guesses. It cannot turn a weak, predictable password into a strong secret. An attacker who obtains the encrypted file can attempt guesses offline, so online login rate limits do not protect this password.
Store the password through a separate, reliable recovery path. Keeping the only password copy inside the encrypted file is circular. Keeping it in an unprotected note beside the file may defeat the intended protection. Choose storage according to who needs access and what loss scenarios matter.
| Component | Role | What it does not solve |
|---|---|---|
| Passphrase | Secret input to key derivation | Recovery if every copy is lost |
| Salt | Separates password-derived keys across files | Weak password guessing by itself |
| IV | Supports safe authenticated encryption use | A substitute for correct implementation |
| Authentication tag | Detects invalid ciphertext under the derived key | Proof of who originally created the file |
| Verified backup | Supports recovery after loss or corruption | Confidentiality if its password handling is poor |
Perform a complete saved-file round trip
Create a small sample containing recognisable text and non-ASCII characters, or choose a disposable binary file. Calculate its SHA-256 with the file checksum tool and keep the digest privately with the test record.
Encrypt the sample, save the downloaded .fpsvault file and close or reset the operation. Then select the saved encrypted file for decryption and enter the passphrase from the storage method you intend to use. This checks the downloaded artifact and your password retrieval path, not merely data still held in the original tab.
Save the decrypted output and compare its complete checksum with the original. Open it in the intended application as an additional usability check. Keep the original until both checks succeed. A matching filename alone does not establish byte recovery.
Repeat with a representative file size and filename before adopting the workflow. Browser memory limits and file-handling behaviour can differ from the tiny sample. The current tool applies a size limit and reads data into memory, so it is not designed as a streaming archive system for arbitrarily large files.
Interpret decryption failures carefully
A wrong passphrase, corrupted file or incompatible format can cause decryption to fail. An authenticated-encryption failure does not necessarily tell you which of those occurred. Preserve the encrypted file and avoid repeated edits to its header or bytes in an attempt to make it open.
Confirm that you selected the intended encrypted file and the matching password record. Check for accidental spaces or a different Unicode representation in the passphrase if it was copied through another application. Do not normalise or trim passwords silently; exact input matters to key derivation.
If you have another verified backup, test that copy without overwriting the failing one. Comparing file sizes and complete digests can help identify corruption during transfer. A backup that has never been decrypted is less useful evidence than a previously verified recovery copy.
Know what remains visible outside encryption
The format encrypts original filename metadata internally, but the downloaded output name can still include the source filename with a vault extension. The encrypted file's size and the fact that it exists also remain visible to storage providers and people who can inspect the folder.
If the filename itself is sensitive, rename the saved encrypted artifact according to your storage plan. Keep an index in a secure location if needed. Renaming the outer file does not change its encrypted content, but losing the mapping can make recovery confusing.
Encryption does not remove copies already present in downloads, recent-file lists, cloud sync history or backups. Decide how originals are handled only after recovery is verified, and follow the storage system's actual deletion and retention behaviour.
Consider the browser and device environment
The tool processes file bytes and passphrases locally in the page. That avoids uploading the selected file through this application, but the browser, extensions and operating system remain part of the environment. A compromised endpoint can observe data before encryption or after decryption.
Use a trusted device and the intended application version for sensitive work. Avoid adding unrelated scripts or extensions to the environment during the operation. Local processing is a useful data-flow property, not a claim that every possible endpoint threat has been eliminated.
Resetting the form removes application references and clears visible fields, but JavaScript cannot promise secure erasure of every memory copy. Do not describe closing the tab as certified memory sanitisation. Manage the overall device and storage environment according to the sensitivity of the files.
Plan how another authorised person would recover the file
If someone else needs access, provide the encrypted file and the password through appropriately separate channels and confirm they can use the compatible decryptor. Do not assume that sending an encrypted attachment alone completes a usable handoff.
Use a disposable sample first when setting up a shared process. Agree on format, password retrieval and what to do if a recipient loses access. A successful test by the sender does not establish that the recipient's browser or environment supports the same workflow.
For organisational records, define ownership when staff leave or accounts are lost. A personal password manager entry may be insufficient for a business recovery requirement. Choose an approved shared recovery mechanism rather than relying on one person's memory.
Test an intentionally altered copy
For a disposable sample, change a byte in a separate copy of the encrypted artifact and confirm that decryption rejects it. Keep the valid sample untouched. This demonstrates the authentication failure path and the interface’s handling of an unusable file. It does not constitute a cryptographic audit, but it verifies that the ordinary workflow does not silently offer corrupted plaintext as a successful recovery.
Frequently asked questions
Can the site recover a forgotten passphrase?
This workflow has no password recovery service or stored recovery key. If the passphrase and every usable backup are lost, the encrypted data may be unrecoverable. Establish the recovery method before deleting originals or relying on the encrypted copy.
Does a successful decrypt prove who sent the file?
It shows that the data authenticated under the password-derived key and format rules. Anyone with the password can create another valid encrypted file. Sender identity or non-repudiation requires a separate authenticated communication or signature design.
Why do two encryptions of the same file differ?
Fresh salt and IV values produce different encrypted outputs even with the same file and passphrase. That is expected. Compare recovered plaintext bytes when checking a round trip, rather than expecting encrypted files to have identical hashes.
Can another archive application open .fpsvault?
Not merely because it supports AES. Formats also define key derivation, metadata, headers and byte layout. Keep a compatible decryptor and documentation, and choose a more interoperable workflow if your long-term requirements demand one.
Does the tool upload my file?
The included implementation processes the selected bytes in the browser and creates a local download. Review the deployed application's data handling if its code changes. Local processing does not remove the need to trust the browser and device environment.
When is it reasonable to remove the original?
Only after verifying a saved encrypted copy decrypts to the original bytes and confirming a reliable password and backup plan. Consider all retention and recovery requirements first. Encryption success alone is not enough evidence to destroy the only unencrypted source.
What should I keep with the recovery instructions?
Record the format version, compatible application, password retrieval method and date of the last successful recovery test. Keep sensitive secrets in their intended secure store rather than in public notes. Review the process after tool or storage changes.