Zero-Knowledge Browser Cryptography: How Web Crypto API (SubtleCrypto) Keeps Secrets Local

A while back, an infrastructure engineer I was collaborating with needed to generate a temporary root secret for a new database replica. Before I could say anything, he opened a browser tab, searched for “random password generator online,” clicked the first result, generated a twenty-character password, and pasted it into our server configuration.

I made him change it immediately.

When I opened DevTools on that popular generator site, my suspicions were confirmed: every time you clicked “Generate,” the page fired an asynchronous POST request to an external server. The server created the password, logged the IP address, and sent the string back over HTTP.

Think about the attack surface: whoever owns that server—or any proxy, logging service, or compromised cloud bucket in between—now has a permanent record of an infrastructure password.

People often assume that doing real cryptography requires a heavy backend server or dedicated command-line utilities like OpenSSL.

That used to be true fifteen years ago. It is completely false today.

Modern web browsers come equipped with the Web Crypto API (window.crypto.subtle). It is a native, hardware-accelerated cryptographic subsystem built directly into the C++ and Rust engines of Chromium, Firefox, and WebKit. It lets you encrypt files, derive keys, and generate true random values directly in local memory.

Here is how zero-knowledge browser cryptography works, why AES-GCM and PBKDF2 protect your files, and how to verify cryptographic operations without trusting external cloud backends.

What Is SubtleCrypto and Why Is It Named That?

If you open your browser console and type window.crypto.subtle, you might wonder why the W3C standards committee chose the word “subtle.”

It is an intentional, self-deprecating inside joke by cryptographers: cryptography is full of subtle algorithmic traps where a single minor implementation mistake—like reusing an initialization vector or using an unauthenticated cipher mode—completely destroys your security guarantees.

Unlike older JavaScript libraries like Crypto-JS, which attempted to execute cryptographic math inside interpreted JavaScript code, SubtleCrypto is an interface to native system libraries (such as BoringSSL in Chromium and NSS in Firefox).

When you call crypto.subtle.encrypt(), the heavy mathematics runs in optimized assembly instructions on your device’s CPU. Keys are stored in non-extractable internal memory buffers, meaning untrusted third-party scripts on the page cannot inspect or dump the raw cryptographic key bytes.

Symmetric Encryption: Why We Use AES-GCM (Not AES-CBC)

When encrypting files or documents in the browser, the gold standard algorithm is AES-GCM (Advanced Encryption Standard in Galois/Counter Mode) with a 256-bit key length.

For years, older systems relied on AES-CBC (Cipher Block Chaining). While CBC provides confidentiality, it does not provide authenticity. If an attacker tampers with a single byte in a CBC-encrypted ciphertext, the decrypted plaintext produces garbage, but the decryption algorithm doesn’t know that tampering occurred. Attackers exploited this flaw to perform padding oracle attacks (such as the famous POODLE exploit).

AES-GCM is an Authenticated Encryption with Associated Data (AEAD) cipher.

When AES-GCM encrypts your data, it outputs two things:

1. The encrypted ciphertext.
2. An authentication tag (a 128-bit checksum generated during encryption).

When you decrypt the file, the algorithm computes the authentication tag across the ciphertext. If even a single bit of the file has been altered, corrupted, or tampered with by a malicious intermediary, the decryption operation fails immediately and throws an error before outputting any corrupted plaintext.

That guarantee is why our Encrypt & Decrypt Files Local Browser tool uses AES-GCM exclusively.

The Initialization Vector (IV) Rule You Must Never Break

In AES-GCM, you never encrypt plaintext with just a key. You also provide an Initialization Vector (IV), typically 12 bytes (96 bits) of random data.

The IV ensures that if you encrypt the same file twice with the same password, the two encrypted outputs look completely different to an observer.

Here is the cardinal rule of AES-GCM: never reuse an IV with the same key.

If you encrypt two different messages using the exact same key and the exact same IV, an attacker can XOR the two ciphertexts together, cancel out the keystream, and recover portions of the plaintext without ever knowing your password.

When our file encryption utility processes an input, it generates a brand new, cryptographically random 12-byte IV using crypto.getRandomValues() for every single operation. That IV is prepended to the final output file so the decrypter can read it during decryption.

Turning Passwords into Keys with PBKDF2

Humans cannot remember 256-bit random binary keys (0x3F, 0x8A, 0x12...). We remember passwords like "Correct-Horse-Battery-Staple-2026".

To convert a human password into a high-security cryptographic key, we use PBKDF2 (Password-Based Key Derivation Function 2).

PBKDF2 takes three inputs:

1. Your passphrase.
2. A unique salt (16 bytes of random data that prevents precomputed rainbow table attacks).
3. An iteration count.

PBKDF2 passes your password through a hash function (like HMAC-SHA-256) hundreds of thousands of times in a cryptographic loop.

Why the high iteration count?

To make brute-force attacks computationally expensive. If a hacker attempts to guess your password by testing millions of possibilities per second on a modern GPU, high iteration counts force their hardware to spend massive computational cycles on every single guess, making automated dictionary attacks practically impossible.

Password Entropy: Why Length Trumps Complexity

Speaking of passwords, how do you know if a password is actually strong?

The traditional corporate advice—requiring an uppercase letter, a number, and a punctuation symbol—is outdated. What actually determines password strength is information entropy, measured in bits:

$$E = L \times \log_2(R)$$

Where:

• $L$ is the character length of the password.
• $R$ is the size of the character pool (lowercase letters = 26, alphanumeric = 62, full ASCII symbols = 95).

A 10-character complex password like P@$$w0rd1! provides roughly 65 bits of entropy. A 20-character passphrase made of simple lowercase words separated by hyphens (laptop-coffee-window-train) provides over 85 bits of entropy—exponentially harder to crack while being far easier for a human to type.

You can audit your credentials with our Check Password Entropy utility, or generate high-entropy passphrases locally using the Secure Offline Password Generator.

And if you ever need to verify that a file downloaded from the web hasn’t been altered in transit, calculate its cryptographic signature using the SHA-256 Hash Generator.

Cryptography Belongs on Your Device

The entire point of encryption is to protect your information from unauthorized access. If you upload your plaintext to a remote cloud server to perform the encryption, you have already surrendered the security perimeter.

By performing all key derivation, AES-GCM encryption, and password generation using the native Web Crypto API inside your browser, your unencrypted data never touches a network interface.

Keep your passwords long, verify your initialization vectors, and if you need an encryption standard or cipher suite that we don’t currently offer, let me know through the Suggest a Tool page.