Encrypt a file without it leaving your device
AES-GCM with a key derived from your password, performed by your browser's own Web Crypto implementation. The file is never uploaded, the password is never stored, and no part of this runs on a server.
Encrypt
Not by you, and not by us — there is no us in this process. The key exists only while the page is open, nothing is stored, and there is no account, no recovery email and no back door. If the password is lost, the file is lost. Write it down somewhere safe before you close this tab.
Processed locally in your browserNothing you enter here is uploaded, logged or sent to any server.
Exactly what is done to your file
Nothing here implements cryptography. Every step below is performed by crypto.subtle, the implementation built into your browser.
- A random 16-byte salt and a random 12-byte nonce are drawn from
crypto.getRandomValues— fresh ones for every encryption, never reused. - Your password and the salt go through PBKDF2-HMAC-SHA-256 at 600,000 iterations to produce a 256-bit key. That figure is OWASP's current recommendation for this function.
- The file, and the filename if you asked for it, are encrypted with AES-256-GCM. GCM is authenticated encryption: it produces a tag that detects any later change to the ciphertext.
- The container header — version, flags, iteration count, salt and nonce — is passed to GCM as additional authenticated data, so it is covered by the same tag and cannot be edited undetected.
The password and the derived key are never written into the file. You can check that claim yourself: the test suite searches the produced bytes for both and fails if either appears.
The container format, in full
Documented because a format nobody can read is a format you cannot get your data out of without this page.
What changed in version 2. Version 1 left the header outside the authenticated data, so the recorded iteration count could be altered — not enough to reveal anything, but enough to make a correct password look wrong. It also had no bound on that count, so four edited bytes could ask your browser for four billion rounds. And it always stored the filename, then saved the result as <original>.tfenc, which put the name in the clear on disk while the page said it was inside the encrypted payload. It was, and it also was not.
Version 1 files still open here, and will continue to. Breaking files that already exist in order to tidy a format would be the worse error.
Why PBKDF2 and not Argon2
Because PBKDF2 is the only password-hashing function Web Crypto implements, and the alternative is shipping a WebAssembly build of somebody else's memory-hard function — more moving parts, a supply-chain question, and a considerably larger thing to get wrong in a page that is meant to be auditable.
The honest consequence: PBKDF2 is weaker per unit of work than Argon2id or scrypt against an attacker with GPUs, because it is not memory-hard and parallelises well. 600,000 iterations of SHA-256 is a real cost — you will feel it on this page — but it is not the same protection a memory-hard function gives. The strength of this file rests mostly on the password you choose, which is why the strength indicator is there and why the tool nags about it.
What this tool does not claim
No tool on this site is described as unbreakable, military grade, or completely secure, because none of those phrases means anything a person could check. What is written down instead is which standard is used, which library implements it, and what the tool has been tested against.
Everything here runs in your browser using its built-in Web Crypto implementation. Nothing is uploaded, and there is no server that could receive it. That is a real and checkable property — open your browser's network tab and use the tool.
What the saved file gives away
Its size, near enough — the container adds a fixed 40 bytes plus a 16-byte tag, so an observer learns the original length to within a few dozen bytes. If that matters, pad the file before encrypting.
Its name, if you let it. The file is saved as <original>.tfenc by default because that is what people expect, and it means the name is sitting on disk in plain view. Turn off "remember the original filename" and the saved file gets a neutral name with nothing in it — and the name is not stored inside the container either.
That it was encrypted by this tool, from the six-byte signature at the start. The container does not try to look like anything else.
Choosing a password for this
This is one of the few places where the password is the entire defence. There is no rate limit to slow an attacker down, no account to lock, no second factor — whoever has the file can try passwords against it as fast as their hardware allows, forever.
Use a generated passphrase. Seven random words is around 64 bits, which is far beyond what a wordlist attack reaches, and you can type it. A password you invented yourself, however clever it feels, is drawn from a much smaller space than you think.
Related
Text encryption uses the same container for a message you can paste. The hash calculator records what a file looked like before you encrypted it.
Questions people actually ask
Is my file uploaded?
No. It is read into your browser's memory, encrypted there by the browser's own Web Crypto implementation, and saved straight back to your disk. There is no upload step and no server on our side that could receive it — watch the network tab while you use it.
What exactly is used?
AES-256-GCM for the encryption, with a key derived from your password by PBKDF2-HMAC-SHA-256 at 600,000 iterations, and a fresh random 16-byte salt and 12-byte nonce for every single encryption. All of it performed by crypto.subtle. The container header is passed to GCM as additional authenticated data so it cannot be edited undetected.
Why PBKDF2 rather than Argon2?
Because PBKDF2 is the only password-hashing function Web Crypto provides, and the alternative is shipping a WebAssembly build of a memory-hard function — more moving parts and a supply-chain question in a page meant to be auditable. The honest consequence is that PBKDF2 is weaker per unit of work against GPU attackers, which is why the strength of your file rests mostly on the password you pick.
Can you recover my file if I forget the password?
No. There is no account, no key escrow, no recovery email and no back door. The key exists only while the page is open and is never stored anywhere. If the password is lost the file is unrecoverable, by us or anyone else.
Why does it say "wrong password, or the file has been altered" rather than which?
Because telling you which would tell an attacker holding your file which. Knowing that a password was correct but the file was damaged, versus that the password was wrong, is exactly the information that makes guessing efficient. The two are reported together on purpose.
What does the encrypted file reveal?
Its approximate size — the container adds a fixed 40 bytes plus a 16-byte tag. That it was made by this tool, from the six-byte signature. And the original filename, if you leave that option on, both inside the container and in the saved file's name. Turn it off and neither carries it.
Can I decrypt a file made by the older version?
Yes. Version 1 containers still open and will continue to. They are marked as such when you open them, because their header was not covered by the authentication tag; re-encrypting produces a version 2 file where it is.