How Browser-Based File Encryption Works

When you encrypt a file on SecretPNG, the entire process happens inside your browser tab. The file is read from your device, encrypted in memory, and handed back to you as a download. Nothing is uploaded, no account is required, and no server ever sees the file, your password, or the keys derived from it.

This is possible because modern browsers ship with the Web Crypto API, a standardized set of cryptographic primitives implemented natively by the browser itself. SecretPNG uses that API rather than custom cryptography, which means the core math runs in the same well-tested code the browser uses for its own security features. Because everything runs client-side, the core tools also keep working offline once loaded and can be installed as a progressive web app.

From password to key

A password on its own is not an encryption key. To turn one into the other, SecretPNG uses PBKDF2 with HMAC-SHA-256 and 600,000 iterations, the iteration count currently recommended by OWASP for this configuration. PBKDF2 deliberately makes each password guess expensive: an attacker who obtains an encrypted file must repeat all 600,000 hashing rounds for every candidate password they try.

Each file also gets a unique, randomly generated 16-byte salt. The salt is stored alongside the ciphertext and ensures that the same password produces a different key for every file. That defeats precomputed lookup attacks and prevents two files encrypted with the same password from revealing that they share one.

Encrypting with AES-256-GCM

The encryption itself uses AES with a 256-bit key in Galois/Counter Mode (GCM). AES is the symmetric cipher standardized by NIST in FIPS 197, and GCM, specified in NIST SP 800-38D, provides authenticated encryption: alongside confidentiality, it produces an authentication tag that lets the decrypting side detect any modification to the ciphertext. If even one bit has been altered, decryption fails cleanly instead of returning silently corrupted data.

SecretPNG does not encrypt your file directly with the password-derived key. Instead, it generates a random 256-bit file key, encrypts the data with that, and then wraps the file key using the key derived from your password. This layered design lets the same file key also be wrapped by an optional recovery key, shown once at creation time, without re-encrypting the underlying data.

Chunks, nonces, and tamper detection

Large files are processed in 1 MiB chunks using the published STREAM construction. Each chunk gets its own nonce built from a random prefix, a counter, and a final-chunk flag. Because the counter and the flag are bound into every nonce, an attacker cannot silently truncate the file, reorder chunks, or splice in chunks from another file: any such change breaks authentication and decryption stops with an error.

Chunking also keeps memory use predictable, so the tool can handle files far larger than it could if it had to hold the whole file and its ciphertext in memory at once.

The .svault container format

The output is written in SecretPNG's documented, versioned container format (.svault, version SPV1). The format specification is public, so you are not locked in: anyone can implement a compatible decryptor from the documentation alone. Filenames and folder structure inside a vault are encrypted along with the content, so the container does not leak what it holds.

What this means in practice

Browser-based encryption changes where you place your trust. You do not have to trust a server with your data, because your data never reaches one. You do have to trust the code delivered to your browser, the browser itself, and the device you run it on. Understanding that boundary is the key to using any encryption tool well.

• Your file, password, and keys stay on your device from start to finish.
• Authenticated encryption means tampering is detected, not just hidden.
• A unique salt and a high iteration count slow down password guessing.
• The open container format means your data is not tied to one vendor.