Your files never leave your device. All processing happens locally in your browser.
How do I password-protect a file online for free without uploading it?
Open the File Encryptor, drop in any file and choose a passphrase, then click Encrypt & download — you get back a <code>.enc</code> file sealed with authenticated AES-256-GCM. To open it, drop the <code>.enc</code> file back in (the tool auto-detects it), enter the same passphrase and click Decrypt to restore the original file and its name. Everything runs locally in your browser via the Web Crypto API; the file is never uploaded, and a lost passphrase means the file cannot be recovered.
Encrypt any file type with AES-256-GCM (authenticated) + Argon2id key derivation
The passphrase is stretched with memory-hard Argon2id (64 MiB, 3 passes) and a fresh random salt
Decryption needs only the .enc file and the passphrase — the filename is stored encrypted
A wrong passphrase or a tampered/truncated file fails the GCM authentication tag
100% client-side in a Web Worker — nothing is uploaded, no server, no CDN
What is
File encryption (client-side, AES-256-GCM)
File encryption converts a file into an unreadable ciphertext that can only be restored with the correct secret. This tool performs it entirely in the browser: a passphrase is stretched into a 256-bit key with the memory-hard Argon2id key-derivation function and a fresh random salt, then the file is sealed with AES-256-GCM — an authenticated cipher that both hides the data and detects any modification via a Galois/Counter Mode tag. The result is a self-describing <code>.enc</code> container that stores the salt, KDF parameters and an encrypted copy of the filename, so decryption needs only the file and the passphrase. It is a convenient file-level aid, not whole-disk or high-assurance encryption.
No. The file is encrypted and decrypted entirely in your browser and never leaves your device.
Encryption runs 100% client-side using the browser’s native Web Crypto API inside a Web Worker. Your file is read into memory, the passphrase is stretched with Argon2id (bundled as inlined WebAssembly, so there is no CDN or download), and the bytes are sealed with AES-256-GCM — there is no upload, no server, no telemetry and no network request in the encryption path. The passphrase and the plaintext exist only in this tab’s memory and are erased when you close it. The only optional network use anywhere on the site is consent-gated ads, which never see your file.
The file is permanently unrecoverable — there is no backdoor, reset or recovery.
Security depends entirely on your passphrase. Because the key is derived from the passphrase alone and never stored, there is no way to recover an encrypted file without it — no master key, no reset link, no support override. If the passphrase is lost, the ciphertext is effectively random data forever. Choose a long, unique passphrase (or use the built-in generator) and store it in a password manager. This is also why a weak or reused passphrase is the main risk: Argon2id makes offline guessing far more expensive, but it cannot rescue a guessable secret.
Argon2id derives a 256-bit key from your passphrase, and the file is sealed with authenticated AES-256-GCM.
The passphrase is stretched with Argon2id — the memory-hard, GPU-resistant KDF recommended by OWASP — using 64 MiB of memory, 3 passes and a fresh 16-byte random salt per file. The resulting 256-bit key encrypts the file with AES-256-GCM, an authenticated cipher (AEAD) that produces a tag detecting any tampering. The file is processed in 1 MiB chunks, each with a unique nonce and bound to the header and its position as additional authenticated data, so reordering, truncation or header edits all fail authentication. The algorithms are standard and strong; the practical security ceiling is your passphrase and the fact that browser crypto cannot defend a device that is already compromised.
Large files are limited by your device’s memory, and the .enc container only opens in this tool.
The whole file is held in memory during processing, so very large files (several GB) are bounded by available RAM and may fail on phones or low-memory machines — desktop browsers handle larger files better. The <code>.enc</code> format is specific to this tool: it uses a custom self-describing header with an “ATEN” magic marker, so you must decrypt it here, not with OpenSSL, GPG or 7-Zip. For whole-disk encryption, cross-tool interoperability or high-assurance needs, use audited software such as VeraCrypt, age or GPG instead.
Detailed Explanation
📖How It Works
What the File Encryptor Does
The File Encryptor is a 100% client-side tool that password-protects any file and restores it later. To encrypt, the user drops in a file and enters a passphrase; the tool derives a 256-bit key and seals the file with authenticated AES-256-GCM, producing a downloadable .enc container. To decrypt, the user drops the .enc file back in — it is auto-detected — enters the same passphrase, and gets the original file and filename back. The passphrase, the file and the derived key never leave the browser; there is no upload, no account and no server involvement of any kind.
Encrypts any file type into a self-describing .enc container
Decrypts with only the .enc file and the passphrase — no key file needed
Auto-detects encrypted files by their header magic marker
Restores the original filename, which is stored encrypted, not in plaintext
Everything runs in the browser — the file is never uploaded
⚙️Methodology
How Encryption Works
A pure engine wraps a golden client-side crypto core (fileCrypto.ts) that runs in a Web Worker. The passphrase is stretched into a 256-bit key with Argon2id (hash-wasm, WASM inlined — no CDN) using a fresh 16-byte random salt, 64 MiB of memory and 3 passes. The file is then encrypted in independent 1 MiB chunks with AES-256-GCM; each chunk uses a unique nonce (baseNonce concatenated with a counter) and binds the header, the chunk index and a last-chunk flag as additional authenticated data, so reordering, truncation or header tampering all fail authentication. Chunk zero is an encrypted metadata record holding the original filename and size, so the name never appears in plaintext. The container starts with an ATEN magic marker plus a version and the KDF parameters, so files stay decryptable as defaults evolve.
AES-256-GCM in 1 MiB chunks, each with a unique nonce
Header, chunk index and last-chunk flag bound as additional authenticated data (AAD)
Filename and size stored in an encrypted metadata chunk, never in plaintext
Self-describing, versioned container with an ATEN magic marker
🔧Technical Details
Authenticated Encryption and Randomness
AES-GCM is an AEAD (authenticated encryption with associated data) cipher: alongside the ciphertext it produces a 128-bit tag that is verified on decryption, so any modification, corruption or wrong passphrase is caught rather than silently returning garbage. All security-relevant randomness — the salt and the base nonce — comes from window.crypto.getRandomValues, never Math.random, and the per-chunk nonce is derived deterministically from the random base plus the chunk counter so a nonce is never reused under the same key. Decryption also validates the plaintext header up front and rejects out-of-range KDF parameters, guarding against a hostile .enc file that tries to force an excessive memory allocation before authentication.
AES-256-GCM verifies a 128-bit authentication tag on every chunk
Salt and base nonce come from crypto.getRandomValues (never Math.random)
Per-chunk nonces are unique — no nonce reuse under the same key
A wrong passphrase or tampered file fails authentication with a clear error
Hostile KDF parameters in a .enc header are rejected before derivation
⚠️Limitations
Honest Limitations
The cryptography is standard and strong, but the practical security ceiling is the passphrase: a weak or reused passphrase can be brute-forced offline, and Argon2id raises the cost without making it impossible. There is no backdoor and no recovery — a lost passphrase means the file is permanently unrecoverable, so it must be saved in a password manager. Because the whole file is processed in memory and assembled into a Blob, very large files (several GB) are bounded by available RAM and can fail on phones or low-memory devices. The .enc container is specific to this tool and cannot be opened by OpenSSL, GPG or 7-Zip. And browser-based encryption cannot protect against malware, a keylogger or an already-compromised device. This is a convenient file-level aid, not whole-disk or high-assurance encryption — for those, use audited tools such as VeraCrypt, age or GPG.
Security depends on passphrase strength — weak passphrases can be brute-forced
No recovery: a lost passphrase makes the file permanently unrecoverable
Very large files are limited by the device’s available memory
The .enc format only opens in this tool, not OpenSSL/GPG/7-Zip
Not a substitute for whole-disk or vetted high-assurance encryption
🔒Privacy & Security
Private by Design
Everything happens on the user’s device. The file is read into memory, the passphrase is stretched with Argon2id (inlined WebAssembly, no CDN and no download), and the bytes are sealed or opened with AES-256-GCM inside a Web Worker — there is no network request, no upload, no logging, no server and no CDN anywhere in the crypto path. The passphrase, the plaintext and the derived key exist only in the tab’s memory and are erased the moment the tab closes; nothing is persisted, added to history or synced. The tool works offline once cached, supports dark mode and a mobile-first responsive layout, and has no analytics or telemetry. The only optional network use anywhere on the site is consent-gated ads, which never see the file. This matters because the entire point of encrypting a file is to keep it private — so the encryption itself must never round-trip through a server.
Encryption and decryption run locally in a Web Worker via Web Crypto
No server, no CDN, no upload, no logging, no telemetry, no account
Passphrase, plaintext and key live only in tab memory — erased on close
Works offline once cached; dark-mode and mobile-first
Only optional network use is consent-gated ads that never see the file
Cryptographic choices and why they were made
Component
This tool
Weaker common choice
Why it matters
Cipher
AES-256-GCM (authenticated)
AES-CBC (no built-in auth)
GCM detects tampering; CBC alone can be silently altered
Key derivation
Argon2id (64 MiB, 3 passes)
PBKDF2 or a raw hash
Memory-hard KDF resists GPU/ASIC brute force
Salt / nonce
Fresh random per file, unique per chunk
Fixed or reused IV
Prevents nonce reuse, which breaks GCM entirely
Filename
Stored encrypted in chunk 0
Left in plaintext header
The name itself can leak sensitive information
Integrity
Per-chunk tag + AAD binding
None
Reordering and truncation are detected, not ignored
Security ultimately depends on passphrase strength; a lost passphrase is unrecoverable. Everything runs locally in the browser; nothing is uploaded. As of July 2026.
