Log In Get Started
Free tool

Encrypt a file with a password

A file sent through a messenger or by email sits on their servers in the clear. Encrypt it here instead: the password becomes a key and the file becomes a set of bytes that cannot be read without it. Encryption and decryption happen in your browser; the file is never uploaded anywhere.

AES-256 with the browser’s built-in crypto. Send the password to the recipient separately from the file.

Drop a file here or

Everything is computed in the browser: the file is uploaded neither to us nor anywhere else. The password is stored nowhere — a forgotten password means a lost file.

What is inside an encrypted file

You get a file with the extension .404enc. At its start there is a format marker, the number of key-stretching rounds, a random salt and an initialisation vector — none of that is secret, and all of it is needed to decrypt the file with the same password. Then comes the AES-256-GCM ciphertext, and the original file name is hidden inside it: a name like "passport-scan.pdf" gives the contents away without any decryption, so the name is hidden too.

GCM mode checks integrity: change a single byte in the file and decryption will not hand back a corrupted result, it will honestly refuse. It behaves the same way with a wrong password — the two cannot be told apart, and that is right.

One limit

The whole file goes into the memory of the tab: hundreds of megabytes the browser survives, tens of gigabytes it does not. For large archives a desktop program is better. And keep in mind that an encrypted file protects the contents, not the fact of sending: that you sent someone something remains visible.

Nearby: a password generator, stripping photo metadata and 404 Send, if the file has to go directly, bypassing other people’s servers.

The contents are closed; the road remains

Whom you sent the file to and when is visible even without its contents. 404 VPN closes that part, and we keep no visit logs.

How it works →

FAQ

guest@404vpn:~$ cat file-crypt-faq.md
[01] $ Why is this better than a password-protected archive? ▸
> Because nothing has to be installed, and because the algorithm here is knowably modern. In old ZIP archives the encryption breaks in minutes, and which encryption a given archive actually uses is not visible from the file. Here it is always AES-256 in GCM mode: it not only hides the contents but also notices if the file was swapped or damaged on the way.
[02] $ Where should I send the password? ▸
> By any channel other than the one carrying the file. The point is the separation: if the conversation is read, it must not contain both the file and the password. Sent the file by email — dictate the password by voice or send it in a messenger, and the other way round.
[03] $ What happens if I forget the password? ▸
> The file stays unreadable for ever. We store no passwords, no keys and no copies of files — there is nothing and no one to recover it from. This is not fine print but the design: a service that can recover your file can also read it.
[04] $ How safe is a five-letter password? ▸
> Not safe. The key is derived from the password with stretching — a million PBKDF2 rounds, to make brute force expensive — but that will not save a short dictionary password. Take three or four unrelated words, or use our password generator: length matters more here than special characters.
[05] $ Is the file really not sent to you? ▸
> Really. Everything is computed by WebCrypto — the same thing the browser encrypts your connections with — and computed inside the tab. While encrypting and decrypting the page makes not a single network request; you can see that in the Network tab of the developer tools.