Encrypt a file
A service that uploads your file to encrypt it has already seen everything it was meant to protect. It held the plaintext and the passphrase. This runs in your browser, makes no request, and works and makes no request.
AES-256-GCM with the key derived from your passphrase. Drop an encrypted file back in to open it again.
Drop any file here
Encrypted here and nowhere else. Drop a .briskfile file to decrypt it again.
or drop a folder here, or paste an image with Ctrl + V
Nothing is uploaded. Open the Network tab before you press encrypt and watch nothing happen.
The one page where the upload question is not a preference
Everywhere else on this site, local processing is a strong convenience argument. Here it is the difference between encryption and a performance of it. If the file goes to a server, that server has the contents and the key, and the encryption it performs protects the file from everyone except the party you just handed it to.
You cannot tell which kind of site you are on by reading the page. Every one of them says the same things. You can tell in five seconds by opening the Network tab, which is the only claim here worth making.
Compress first, then encrypt
This catches people out, and the reason is worth understanding. Compression works by finding repetition and describing it more briefly. Good encryption produces output that is statistically indistinguishable from random noise — which by definition contains no repetition to find.
So zipping an encrypted file saves nothing, and often adds a few bytes of container overhead. Encrypting a zip works exactly as you would hope. If you are sending a folder, make the archive first and encrypt the result.
What the format is, and why it is not a standard one
| Part | Bytes | Purpose |
|---|---|---|
| Header | 4 | Identifies the file as one of ours, so a wrong file fails clearly |
| Salt | 16 | Random per file, so the same passphrase never yields the same key twice |
| IV | 12 | Random per file. Reusing one in GCM is catastrophic rather than untidy |
| Ciphertext + tag | rest | The file, and the authentication tag that detects tampering |
The salt and the IV are not secret and travel with the file, because decryption cannot happen without them. Only the passphrase is secret.
This is a sensible layout rather than a standard one, which is an honest limitation: other software will not open it. If you need a file that any recipient can decrypt with tools they already have, age or GPG are the right answer and this is not. If you need to protect something you will open again yourself, or send to someone you can point at this page, this is simpler than either.
Send the passphrase by another route
The commonest mistake with an encrypted file has nothing to do with cryptography: it is emailing the file and the passphrase in the same message, which reduces the whole exercise to a mild inconvenience for anybody reading the mailbox.
Different channel, ideally a different medium. The file by email, the passphrase by phone or in person. And remember that losing it is final — there is no recovery, which is the point rather than an oversight.
Questions
Is it safe to encrypt a file on a website?
Only if the encryption happens in your browser, and on most sites it does not. A service that uploads your file to encrypt it has received the plaintext and the passphrase — the two things the exercise exists to protect — and you have no way to know what happened next. This page encrypts locally and makes no request, which is checkable with the Network tab open and watch nothing leave.
What encryption is used?
AES-256 in GCM mode, with the key derived from your passphrase by PBKDF2-SHA256 over 310,000 iterations. All of it is your browser’s own WebCrypto implementation. GCM is authenticated, so a file altered after encryption fails to open rather than decrypting into corruption.
What happens if I forget the passphrase?
The file is gone. There is no recovery, no reset, no back door and no support address that can help — which is precisely what distinguishes encryption from a password prompt. The passphrase is asked for twice here for that reason. Write it down somewhere safe before you delete the original.
How large a file can it handle?
Whatever your device can hold in memory, which in practice means hundreds of megabytes comfortably. The whole file is read at once rather than streamed, so very large disk images are better handled by a desktop tool.
Can I open the encrypted file with other software?
Not directly. The output is AES-256-GCM with a small header holding the salt and initialisation vector, which is a sensible format but not one other tools recognise. Decrypt it here, or with a short script if you would rather not depend on this page existing. For interoperability with desktop tools, age or GPG are the better choice.
Should I encrypt before or after compressing?
Compress first, always. Encrypted data is indistinguishable from random noise, and compression works by finding repetition — so zipping an encrypted file achieves nothing at all, while encrypting a zip works perfectly.
What BriskFile will not do to you
-
Your files never leave your device
Every conversion runs in your browser. Open DevTools, watch the Network tab, and you will see no upload — because there is not one.
-
No account, no email, no watermark
Nothing to sign up for and nothing stamped on your images. There is no step between choosing a file and getting it back.
-
No limits at the download button
No daily cap, no file counter, no "upgrade to download". If the tool starts a job, it finishes it.
-
Checkable, not just claimed
Open the Network tab and convert something — nothing goes out. Or load the page, disconnect, and watch it keep working: the tool is already on your machine, and your file never leaves it.